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The  Director  General  Maritime  Engineering  and  Maintenance  (DCMEM)  is 
pleased  to  present  the  Proceedings  of  the  Sixth  Ship  Control  System 
Syrposium  held  at  the  Chateau  Laurier/National  Conference  Centre  corqplex  in 
Ottawa,  Canada,  26-30  October  1981.  This  is  the  sixth  in  a  series  of  sympo¬ 
sia  on  ship  control  systems.  The  First  Ship  Gpntrol  Systems  Symposia  was 
convened  in  1966. 

The  technical  papers  presented  at  the  Syrrposium  and  published  in 
these  proceedings  cover  the  entire  spectrum  of  ship  control  systems  and 
provide  an  insight  into  technological  developments  which  are  continuously 
offering  the  ship  control  system  designer  new  options  in  addressing  the 
conplex  mar*/ machine  operation.  The  microprocessor  and  its  apparently 
unlimited  development  potential  in  future  digital,  distributed  control 
systems  appears  ready  to  reshape  the  conventional  concepts  new  so  familiar 
in  control  system  designs.  There  are  many  concerns  that  the  advantages  of 
the  new  technologies  will  be  negated  by  the  inability  of  training  systems  to 
graduate  technicians  who  can  adequately  cope  with  these  new  systems. 

The  response  to  "Call  Ft>r  Papers"  was  outstanding  and  the  papers 
selection  committee  constrained  fcy  the  time  available  for  presentations,  was 
hard  pressed  to  make  their  final  selections  from  the  many  fine  abstracts 
submitted.  The  final  papers  represent  a  unique  international  flavour  which 
includes  authors  from  every  facet  of  the  ship  control  system  comnunity.  The 
final  program  is  a  balance  of  both  theoretical  and  practical  control  system 
papers. 


These  Proceedings  constitute  the  major  record  of  the  Sixth  Ship 
Control  Systems  Symposium.  The  contents  indicate  the  success  of  the 
Symposium  and  provide  some  insight  into  the  effort  that  was  required  to 
ensure  this  success.  The  Symposium  organizing  committee,  advisory  groups, 
publications  branch,  authors,  session  chairmen,  international  coordinators, 
clerical  and  a&ninistrative  personnel,  and  management  all  provided  positive 
and  cooperative  support  to  the  many  tasks  that  had  to  be  performed  in 
organizing  and  presenting  the  Symposium. 

This  Symposium  has  continued  to  explore  and  present  a  number  of 
specific  aspects  of  ship  control  systems  and  undoubtly  the  next  symposium 
will  include  new  concepts  and  ideas  which  were  unavailable  for  this 
Symposium.  As  in  the  past,  we  hope  these  Proceedings  become  a  source  docu¬ 
ment  on  ship  control  along  with  the  previous  proceedings.  It  is  our  hope 
that  the  Synposium  has  provided  stimulation  to  those  who  will  continue  to 
advance  this  technical  field. 
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WARSHIP  PROPULSION  CONTROL  SYSTEMS  - 


A  CANADIAN  FORCES  PERSPECTIVE 


Captaln(N)  D.J.S.  Reilley,  CF 
Cdr  B.H.  Baxter,  CF 


SUHHARY 

V  The  aim  of  this  paper  to  present  the  dilemma  now  facing  warship 
propulsion  control  systems  designers  as  they  attempt  to  achieve  exacting  system 
performance  requirements  in  an  unstable  technical  and  personnel  environment.  The 
Canadian  Forces  (CF)  experiences  with  the  DDH  280  propulsion  control  system  will 
be  used  to  Illustrate  how  the  failure  to  appreciate  the  Impact  of  technically 
advanced  systems  on  personnel  In  general  and  the  military  training  organization 
In  particular  can  result  In  problems  which  negate  the  advantages  offered  by 
technical  Innovation.  The  influence  of  adverse  demographic  projections  on  the 
designer's  decision  will  be  discussed  and  developed  as  a  critical  factor  in  the 
man-machine  equation.  The  CF  Ship  Integrated  Machinery  Control  System  (SHINMACS) 
concept  will  be  offerred  as  an  option  to  the  propulsion  control  system  designers 
attempting  to  achieve  specified  operational  requirements  within  the  realities  of  a 
personnel  conscious  military  organization. 

INTRODUCTION 

2.  Previous  ship  control  system  symposia  have  served  to  focus  a  new  awareness 
of  adopting  a  total  Integrated  design  concept  when  specifying  systems  for  complex 
warship  designs.  Frequently  the  designer  in  his  eagerness  to  provide  increased 
capability  through  technological  advances  fails  to  adequately  assess  the  impact 
the  new  technology  may  have  on  related  personnel  trainings  systems.  Today  the 
propulsion  control  system  designer,  faced  with  an  accelerating  increase  in  micro¬ 
electronic  components,  must  temper  his  design  decisions  with  an  analysis  of 
previous  designs  and  their  in-service  performance. 

3.  Automation  within  a  manpower  limited  organization  continues  to  receive 
considerable  discussion  and  it  is  generally  conceded  that,  in  those  warship  designs 
where  automation  was  specified  as  integral  to  manning  reductions,  in-service  design 
limitations  resulted  In  unplanned  maintenance  requirements  which  could  only  be  met 
by  the  Introduction  of  material  and  personnel  resources  which  were  designated  to 
other  high  priority  projects.  The  additional  resources  may  resolve  the  technical 
problem  but  the  overall  effect  on  the  designer's  credibility  may  result  in  future 
'design  guidance'  which  effectively  eliminates  new  technical  advances  in  favour 

of  conservative,  time  proven  concepts.  This  loss  of  Initiative  can  result  In 
systems  and  equipments  that  lack  the  flexibility  to  cater  for  changing  personnel 
and  technical  conditions.  A  review  of  the  CF  DDH  280  propulsion  control  system 
Illustrates  how  non-technlcal  considerations  were  able  to  produce  long  term 
operational  problems  which  have  brought  unnecessary  criticism  to  a  significant 
technical  achievement. 

DDH  ?80  EXPERIENCE 

4.  There  is  a  tendancy  to  critically  review  the  decisions  of  previous 

propulsion  control  system  designers  with  a  retrospective  Insight  which  was 
unavailable  to  the  original  design  team.  The  complex  cause  and  effect 
relationships  which  were  at  best  conceptual  design  assumptions  tend  to  crystal ize 
with  the  passing  years  and  criticism  is  directed  at  system  designers  whose  only 
fault  was  In  specifying  a  system  within  the  bounds  of  existing  personnel  and 
budget  realities.  . 


5.  The  OOH  280  is  a  50,000  SHP  C0606  (combined  gas  or  gas)  destroyer 
incorporating  state-of-the-art  1965  technology.  Although  other  navies  and  some 
merchant  vessels  had  experimented  with  gas  turbine  propelled  vessels,  the  DDH  280 
was  the  first  operational  warship  to  successfully  commission  the  COGOG  machinery 
arrangement.  The  propulsion  control  system  includes: 

Propulsion  Control  -  COGOG  50,000  SHP 

.  2  FT  4  (25,000  SHP),  2  FT  12  (3400  SHP) 

Controllable  Pitch  Propellers 

.  Pneumatic,  Hydraulic  Control 

Bailey  760  Sequencer  -  Analogue,  Hard  Wired 

.  Engine  Start,  Stop,  Trips 

.  Engine  Selection 

.  Control  Station  Transfer 

Bailey  750  Data  Logger  -  Digitized  Analogue  Inputs 

.  Periodic  Data  Logger 

Demand  Logger 

.  Alarm  Logger 

6.  These  systems  remain  the  design  basis  for  warships  enterring  service  today 
and  although  the  DDH  280  has  experienced  some  system  failures,  the  overall 
assessment  of  these  control  systems  is  favourable.  The  selection  of  a  pneumatic 
control  system  is  often  questioned  and  the  simple  answer  is  that  in  1965 
electronic  control  systems  were  unproven,  unreliable  and  unavailable.  Granted, 
the  pneumatic  control  system  is  now  technically  obsolete  and  the  maintenance 
resources  necessary  to  support  the  system  are  excessive-,  but  these  problems  are 
resolvable  within  the  normal  technical  updating  process  which  normally 
characterizes  all  vjarships.  Current  CF  DDH  280  update  programmes  include  plans 
to  modernize  the  entire  propulsion  control  system  with  available  1981  technology. 

7.  The  DDH  280  represented  a  quantum  step  forward  in  marine  systems  technology 
which  was  under-estimated  in  terms  of  training  and  support  requirements  necessary 
to  achieve  the  transition  from  steam  to  gas  turbine  technology.  The  gas  turbine 
with  Its  Inherent  high  rotational  speeds  required  a  responsive  control  system 
which  was  beyond  manual  capability.  Initial  crews  were  hand  picked  and  given 
special  technical  training  to  prepare  them  for  the  new  ships.  A  small  group  of 
tradesmen  exhibiting  special  control  system  aptitudes  were  trained  as  control 
system  technicians  but  the  majority  of  DDH  280  marine  engineering  personnel 
received  only  limited  controls  training.  Initial  operating  experiences  pointed 
out  that  necessary  documentation  in  the  form  of  technical  manuals,  drawings  and 
maintenance  procedures  was  inadequate  and  that  fault  finding  and  rectification 
within  the  complex  propulsion  control  system  was  manpower  intensive  and  in  some 
Instances  merely  a  hit  and  miss  exercise.  The  cost  in  preparing  the  necessary 
DDH  280  technical  documentation  today  is  staqgering  and  again  diverts  scarce 
resources.  The  CF  in  1965  was  primarily  a  Y-100  steam  turbine  navy  and  It  was 
almost  10  years  before  the  technical  training  schools  were  able  to  introduce  gas 
turbine  technology  into  existing  training  courses.  In  spite  of  these  shortcomings 
the  DDH  280  has  proven  itself  a  rel lable  propul  sion  system  and  the  hard  lessons 


beamed  will  be  applied  to  all  future  warship  designs  to  ensure  the  design  process 
Integrates  the  technical  and  personnel  requirements  Into  a  total  system  concept. 

DEMOGRAPHIC  INFLUENCES 

8.  Any  decision  to  specify  technically  advanced  concepts  for  warships  In  an 
all  volunteer  military  system  must  be  balanced  by  a  realistic  assessment  of 
demographic  trends.  Failure  to  appreciate  the  Impact  of  adverse  demographic 
trends  can  spell  ruination  for  those  system  designs  which  are  unsupportable  In 
terms  of  human  resources.  Figure  1  Illustrates  the  Canadian  population  in  terms 
of  potential  17-24  year  recruits  for  the  period  1968-1990.  Although  the  curve 
shows  we  are  now  at  the  peak  of  the  *baby  boom',  recruiting  is  less  than  ideal 
and  in  the  next  10  years  the  situation  may  become  critical.  Existing  recruiting 
criteria  with  respect  to  sex,  age  and  education  will  have  to  be  waived  if 
sufficient  recruits  are  to  be  found. 


MALE  AND  FEMALE  POPULATION  AGED  17-24 
IN  THOUSANDS  FOR  TWO  TEAR  PERIODS  1968-1990 


FIGURE  I 


9.  The  recruiting  problem  is  further  complicated  by  educational  trends 
(FIGURE  2)  which  clearly  shows  a  significant  increase  in  that  segment  of  the 
Canadian  school  leavers  who  elect  post  secondary  education.  These  students  do 
not  traditionally  join  the  military,  so  recruiting  quotas  are  filled  from  the 
lower,  less  educated  group,  who  have  chosen  to  opt  out  of  what  Is  generally 
conceded  as  an  ’easy*  school  system.  Their  potential  as  eventual  high  technology 
technicians  is  questionable. 
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MALE  AND  FEMALE  SCHOOL  LEAVERS  IN  THOUSANDS  • 


FIGURE  2 


10.  These  trends  present  the  system  designer  with  a  double  edged  dilemma.  On 
one  side  he  sees  new  technical  innovations  whose  implementation  requires 
recruits  of  higher  skill  levels  than  are  now  in  the  personnel  inventory  while  on 
the  other  side  he  sees  a  shrinking  manpower  pool  characterized  by  less  capable 
recruits.  If  he  abandons  the  new  technologies  for  simpler  systems  which  can  be 
mastered  by  the  available  recruits,  he  soon  realizes  that  the  numerical  realities 


+  i  W1  .not  provlde  the  numbers  of  tradesmen  necessary  to  operate  and 
whlrh ^  !nthe*fySt!mS'  °ne  solution  ^  t0  develop  a  recruiting  and  training  concept 
?  C  PW  /  t^ff1Cifint  hl9-  calibre  ^cruits  from  the  upper  Figure  I  curve. 
rerr,n><  h?  3  recrultln9  concept  designated  lateral  entry  which 

1  /  9h  ChCK!  9:aduates  by  offerring  them  subsidized  education  and  acceler¬ 
ated  rank  upon  graduation.  The  pilot  project  is  now  in  its  second  year  and  initial 
evaluations  are  very  encouraging.  The  lateral  entry  recruit  studies  a  programme 
based  on  the  latest  high  technologies  which  are  planned  for  future  CF  systems  It 
is  expected  that  the  lateral  entry  concept  will  expand  rapidly  in  the  next  few 
years  to  include  all  CF  technical  trades. 


TECHNOLOGY  IN  THE  1 980  *  s 


i  ^^mated  that  today's  ship  control  system  designer  has  available 
to  him  only  10  percent  of  the  1990  technology.  The  advances  in  nticro-eleclonics 
are  occurring  so  rapidly  that  it  is  virtually  impossible  to  develop  a  concert^ 
design  which  will  remain  technically  relevant  over  the  normal  7  to  8  year  warshfD 
acquisition  period.  The  designer  can  at  best  structure  his  design  sothlt 
«t?hI?Cinnn^Me,,^andie<,u1pments  mainta1n  a  flexible  modular  characteristic 
*11  Tat1ve  de''e1°Pments  can  be  adapted  without  total  system  replacement 
t  1  *  rCePtS  °f  Standard  d19lta1  equipment  (SDE)  and  distributive 

system  architecture  appear  very  promising  and  all  ship  designers  and  planners 
are  nHy  f“nd’n9  development  programmes  that  will  demonstrate  theP 
capabilities  of  these  new  system  concepts.  The  CF 1  s  SHINPADS  and  SHINMAr<; 

ar*  bu‘  IS  e?amples  of  th1s  "ew  distributive  concept  whtch  wm  be  “P 

presented  during  the  symposium.  be 
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12.  There  is  a  decision  point  in  every  warship  acquisition  programme  when  the 
system  designers  must  make  their  choice  of  candidate  systems  and  equipments  which 
will  achieve  the  stated  performance  requirements  within  an  acceptable  technical 
risk.  Those  promising  technical  developments  with  excessive  risk  cannot  be 
included  in  the  design  as  tneir  potential  failure  can  result  In  unacceptable  cost 
and  personnel  requirements. 

13.  The  key  to  the  future  systems  is  undoubtedly  the  silicon  chip  with  its 
unbelievable  capacity  to  store  hundreds  of  thousands  of  information  bits  on  a 
postage  stamp  size  Dlock.  The  low  cost,  reliability,  redundancy  and  computing 
power  of  these  chips  make  them  inevitable  components  in  all  systems  and  hardwares. 
Some  chip  manufacturers  are  now  placing  entire  systems  on  a  single  chip  and 
giving  the  control  system  designer  the  capability  to  specify  individual  component 
control  systems  which  were  previously  limited  to  the  overall  or  central  system 
control.  The  entire  control  of  a  gas  turbine  including  fuel  scheduling  is  now 
possible  on  a  single  chip. 

14.  Electronic  and  digital  components  have  demonstrated  high  reliability 
performance  and  designers  are  no  longer  reluctant  to  specify  them  for  ship  control 
systems.  In  most  implications  the  repair  by  replacement  on  exchange  nature  of 
the  electronic  and  digital  components  lends  itself  well  to  the  condition  based 
maintenance  philisophies  which  appear  to  be  evolving  In  most  naval  maintenance 
management  systems. 

15.  The  unprecedented  capabilities  of  the  new  micro-electronics  and  their 
associated  mini -computers  and  mi cro-processors  are  not  without  serious  concerns 
in  the  areas  of  software  costs  which  appear  to  be  rising  at  an  alarming  rate. 
Programmers  for  real-time  sophisticated  military  systems  are  difficult  to  find  and 
the  management  of  software  has  become  a  serious  concern.  Most  system  design 
authorities  are  developing  rigid  software  criteria  which  should  provide  the 
necessary  control  through  standard  digital  equipment  and  software  languages.  The 
eventual  development  of  a  standard  compiler  such  as  ADA  will  do  much  to  resolve 

the  existing  software  problem. 

CANADIAN  FORCES  PROPULSION  CONTROL  PHILOSOPHY 

16.  The  critical  influence  in  all  warship  propulsion  control  design  decisions 
over  the  next  20  years  will  be  the  shrinking  manpower  pool.  Any  decision  which 
fails  to  address  this  reality  will  be  subject  to  severe  criticism  and,  if  not 
challenged  could  result  in  future  manning  problems  which  could  seriously  impact  on 
operational,  capabil ity.  Those  existing  CF  warships  which  are  planned  to  undergo 
mid-life  or  major  conversion  programmes  must  also  be  assessed  against  projected 
manning  reductions  and,  wherever  feasible,  new,  less  manpower  intensive  systems, 
must  be  proposed.  In  determining  the  level  of  technology  which  can  be  supported 
within  the  existing  CF  trade  structure  it  will  be  necessary  to  review  traditional 
recruiting  concepts  to  see  where  new  sources  of  high  calibre  recruits  can  be  found. 
Programmes  such  as  the  current  CF  pilot  project  to  assess  the  feasibility  of 
lateral  entry  must  be  exploited  and  expanded  as  quickly  as  possible.  The  CF  will 
continue  to  observe  Canadian  industry  to  see  how  they  address  similar  technical 
problems  and,  if  compatible,  the  CF  will  adopt  the  proven  ideas  and  concepts  of 
industry.  The  growth  of  controls  and  instrumentation  technicians  in  the  civilian 
sector  has  prompted  the  CF  to  review  its  existing  requirements  for  these 
technicians  and  it  is  conceivable  that  specialized  controls  and  instrumentation 
tradesmen  will  become  a  separate  CF  marine  engineering  trade  in  the  future. 
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17.  The  CF  will  continue  to  work  with  Canadian  industry  in  developing 
equipments  and  system  concepts  which  turn  technical  Innovations  into  available 
propulsion  control  systems.  System  design  criteria  will  be  carefully  stated  to 
ensure  whatever  systems  that  are  developed  address  the  Canadian  requirements. 

18.  Digital,  distributive  systems  incorporating  graphics  and  ergonomically 
designed  displays  and  consoles  appear  most  capable  of  meeting  present  and  future 
Canadian  needs.  The  reliability  and  flexibility  of  electronic  and  digital 
components  should  offer  a  range  of  system  performance  which  is  unavailable  in 
existing  ships  today.  The  silicon  chip  now  provides  a  computing  and  memory 
capability  which  can  be  programmed  to  assist  every  system  operator  in  performing 
his  watchkeeping  duties.  No  longer  will  watchkeepers  be  required  to  memorize 
countless  operating  and  emergency  procedures.  All  system  information  will  be 
stored  and  available  for  instant  recall.  The  ability  to  employ  the  digital 
architecture  as  a  training  simulate-*  will  prove  an  enormous  benefit  if  rising 
fuel  costs  begin  to  limit  sea  training  periods.  SHINMACS  and  other  digital 
systems  which  offer  these  new  concepts  in  control  system  design  are  still  only 
research  and  development  projects  which  will  require  at  least  2  more  years  before 
the  concepts  are  demonstrated. 

CONCLUSION 

19.  The  challenges  of  the  80' s  demand  a  new  awareness  from  propulsion  control 
system  designers  who  are  tasked  with  providing  operationally  capable  warships 

in  an  uncertain  technical  and  personnel  environment.  No  longer  will  the  design 
engineer,  the  research  and  development  scientist  and  the  personnel  planners  be 
able  to  work  in  isolation,  for  failure  of  one  to  totally  appreciate  the 
limitations  of  the  others  may  result  in  new  systems  which  are  unsupportable .  The 
design  engineers  must  step  back  from  his  ever  changing  technical  world  and  assess 
his  ideas  and  concepts  not  only  against  past  designs  but  also  against  the 
projected  rejlities  of  the  future.  Technology  must  not  be  allowed  to  grow 
unchallenged,  but  be  expanded  under  the  positive  control  of  designer  engineers 
whose  ultimate  aim  must  be  to  direct  technical  innovations  towards  total  Integrated 
systems  that  will  achieve  specified  performance  under  the  most  stringent 
conditions  The  task  will  not  be  easy  but  the  cost  of  failure  will  be  absolute. 
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OBJECTIVES  AND  IMPLEMENTATION  OF  FUTURE 
WARSHIP  CONTROL  AND  SURVEILLANCE  SYSTEMS 


by  Cdr.  E.D.M.  Floyd,  R.  N.  ,MOD(PE),  Bath.  UK 
and  Mr.  J.  B.  McHale,  Y-ARD  LTD., Glasgow.  UK 

INTRODUCTION 

At  the  Fifth  Ship  Control  System  Symposium  at  Annapolis,  the  UK  MOD 
presented  a  series  of  inter-related  papers  (References  1-7)  that  covered  the 
activities  that  had  been  undertaken  during  their  research  programme,  and 
outlined  the  major  development  activities  that  they  were  planning  to  initiate.  It 
is  appropriate,  therefore,  that  three  years  later  in  this  paper  and  its  associated 
papers  (References  8  -  11),  an  attempt  should  be  made  to  present  the  progress 
of  these  development  projects,  the  problems  that  have  been  encountered,  and 
the  extent  to  which  the  original  design  objectives  have  been  met.  This  paper 
will  cover  the  broader  aspects  of  where  the  MOD  currently  stands,  and  will  act 
as  an  overview  to  the  other  papers  presented  by  the  MOD,  their  consultants  and 
industry,  which  will  discuss  some  of  the  main  areas  in  greater  detail. 

In  developments  of  this  nature  where  the  maximum  safe  use  of  advanced 
technology  is  being  sought,  it  is  almost  inevitable  that  the  path  leading  from 
the  early  system  concepts  to  the  production  of  a  system  for  installation  in  a 
ship  should  not  be  a  smooth  one.  However  careful  and  conscientious  one  may 
be  in  trying  to  learn  from  the  mistakes  of  the  past,  and  however  forward 
thinking  one  may  be  in  trying  to  identify  the  new  problem  areas,  large  and 
complex  programmes  of  the  sort  that  will  be  described  have  indeed  thrown  up 
unexpected  difficulties,  and  shown  up  certain  shortcomings  in  the  approach  that 
has  been  taken.  These  are  all  covered  in  the  companion  papers,  along  with  the 
steps  that  have  been  taken,  or  have  been  proposed,  to  overcome  them. 

Now  although  it  must  be  stressed  that  in  the  UK  the  developments  under 
discussion  are  by  no  means  finished  nor  the  designs  evaluated,  nevertheless 
it  is  an  excellent  discipline  to  recall  the  original  design  objectives  and  examine 
critically  the  advantages  that  were  foreseen,  to  see  how  far  they  are  being 
realised  in  practice.  Finally  the  lessons  that  have  been  learnt  by  the  MOD,  its 
consultants  and  its  contractors  will  be  highlighted. 

BACKGROUND 

The  analogue  propulsion  control  and  surveillance  systems  that  have  been 
fitted,  and  are  still  being  fitted  in  the  Royal  Navy  gas  turbine  ships,  are 
working  well  and  giving  very  little  trouble.  Failure  rates  are  low,  fault 
finding  facilities  are  good,  and  comprehensive  shore  training  facilities  are 
provided  for  operators  and  maintainers,  and  these  factors,  when  allied  to  the 
GT  propulsion  plant  designs  themselves,  have  resulted  in  a  situation  where 
there  is  no  record  of  any  operator  errors  leading  to  major  machinery  damage. 
This  is  a  far  cry  from  the  record  of  comparable  steam  plants  and  their 
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associated  controls.  The  current  analogue  control  and  surveillance  systems 
are,  however,  of  dated  design,  and,  inevitably,  problems  of  obsolescence 
cannot  be  that  far  off.  It  was  the  realisation  that  a  new  generation  of  control 
and  surveillance  systems  would  be  required  for  machinery  to  be  fitted  in  the 
next  surface  ship  project  that  led  to  the  MOD  setting  up  a  Technical 
Co-ordination  Group  to  propose  a  detailed  programme  of  research  and 
development  work  in  the  Machinery  Control  and  Surveillance  (MC  &  S)  field. 

This  led  in  1975  to  the  setting  up  of  the  MC  &  S  Research  Programme,  the 
full  scope  of  which  was  described  in  a  paper  presented  at  the  Fifth  Ship  Control 
Systems  Symposium  (Reference  1).  The  programme  ranged  from  the 
consideration  of  broad  ship  level  concepts  through  the  spectrum  to  detailed 
hardware  design.  Because  there  was,  at  the  time,  no  specific  ship  programme 
at  which  the  work  was  directed,  it  was  essential  to  ensure  that  the  results  were 
applicable  to  the  widest  possible  range  of  ship  types.  The  objectives  set  for 
these  studies  were: 

(a)  To  establish  the  broad  requirements  for  automation  in  future  ship  systems 

and  establish  a  rational  basis  for  arriving  at  the  optimum  balance  between 

man  and  automation. 

(b)  To  prepare  for  the  introduction  of  new  technology  in  the  most  cost 

effective  applications. 

It  is  not  necessary  here  to  detail  all  the  outputs  from  the  twenty  or  more 
studies  that  were  undertaken  by  industry,  universities,  MOD  consultants  and 
other  Directorates  within  the  MOD,  but  note  will  be  taken  of  certain  key 
decisions  that  emerged  which  were  central  to  the  whole  strategy  that  evolved. 

Although  the  first  development  project  to  be  undertaken  was  for  surface 
ship  propulsion  systems,  in  fact  the  research  activities  had  been  undertaken  to 
look  at  the  full  spectrum  of  ship  machinery.  Current  RN  ships  are  fitted  with 
a  wide  range  of  analogue  electronic,  fluidic,  pneumatic  and  mechanical  control 
systems,  and  it  was  realised  that  major  cost  savings  would  stem  from  the 
adoption  of  common  policies  and,  wherever  possible,  common  technology.  A 
committee  was  set  up  within  the  MOD  with  the  task  of  ensuring  that,  in  advance 
of  an  actual  ship  design,  all  developments  in  this  field  would  lead  to  equipments 
that  would  be  compatible,  one  with  another,  in  a  ship  environment.  Every 
effort  was  to  be  made  to  ensure  that  a  high  degree  of  commonality  was 
achieved  in  areas  such  as  the  level  of  automation  to  be  fitted,  the  design 
standards  to  be  applied,  the  concepts  of  machinery  operation  and  the  approach  to 
vulnerability. 

From  the  programme  of  research  arose  the  concept  that  future 
propulsion  control  systems  will  be  based  on  digital  technology  using 
microprocessors  and  multiplexing  in  a  distributed  configuration,  as  opposed  to 
the  centralised  concept  used  in  the  current  generation  of  analogue  systems.  The 
decision  was  taken  to  initiate  a  major  development  programme  around  this 
concept  and  design  such  a  control  and  surveillance  system  for  a  notional  ship 
with  a  propulsion  package  of  4  SMI  A  Spey  Gas  Turbines  in  a  COGAG  arrange¬ 
ment  driving  into  a  controlled  pitch  propeller  (CPP  system).  This  came  to  be 
known  as  the  Reference  Ship.  In  practice  it  has  been  found  that  the  normal  lead 


A  2-2 


time  between  the  tabling  of  a  Naval  Staff  Target  for  a  new  Class  of  ships  and 
the  time  when  production  equipment  is  required  at  the  dockside,  is  inadequate 
for  the  proper  and  orderly  development,  evaluation  and  production  of  a  new 
control  system,  and  thus  the  aim  was  set  to  produce  a  system  that  was  as  near 
ship  independent  as  possible.  The  role  of  simulation  studies  In  the  design  and 
development  of  control  systems  is  discussed  in  an  associated  paper 
(Reference  8). 

CURRENT  DEVELOPMENT  PROGRAMME 

The  current  development  programme  consists  of  a  number  of  areas  of 
activity,  some  of  which  are  in  a  major  development  phase,  while  other 
activities  are  progressing  at  a  slower  pace.  Those  where  the  greater  effort  is 
being  applied  presently  are  the  Propulsion  Control  System  Demonstrator,  the 
Propulsion  and  Auxiliary  Secondary  Surveillance  System  (PASS),  and  the 
Evaluation  Centre.  The  activities  currently  being  pursued  in  a  lower  key  are 
Continuation  Trainers,  Auxiliary  Control  Systems,  and  the  design  of  Ship 
Control  Centres  (SCC). 

Propulsion  Control  System  Demonstrator 

As  discussed  earlier,  there  was  a  need  to  gain  experience  in  digital 
technology  systems  and  therefore  it  was  decided  to  design  and  manufacture  a 
"Demonstrator"  system  which  could  be  evaluated  at  the  Evaluation  Centre  from 
an  operational  and  user  viewpoint,  while  allowing  valuable  experience  to  be 
gained  in  the  implementation  of  this  new  technology.  The  Demonstrator  system 
encompassed  the  Propulsion  Control  and  primary  surveillance  based  on  the 
machinery  configuration  of  the  Reference  Ship  as  described  above.  The  concept 
was  derived  from  the  test  rig  system  reported  at  the  Fifth  Ship  Control  Systems 
Symposium  (Reference  5)  and  comprised  a  distributed  computer  system  as 
shown  schematically  in  Figure  A.  Briefly  each  major  item  of  plant  and  every 
control  position  would  have  distributed  intelligence  in  the  form  of  a  micro¬ 
computer  together  with  the  unit  which  undertook  the  System  Control  functions 
called  the  System  Control  Unit  (SCU).  The  communications  between  these 
computers  would  be  by  means  of  high  speed  serial  communication  lines.  It  was 
planned  that  the  quality  of  the  hardware  build  would  be  pre-production 
standard  and  the  software  to  full  long  life-time  production  standards.  At  the 
time  of  writing  this  paper  the  system  hardware  has  been  completed  and  system 
communications  are  being  set  to  work,  with  the  system  integration  and  setting  to 
work  at  the  Evaluation  Centre  phases  still  to  follow.  On  completion  a  decision 
will  be  made  as  to  whether  the  system  will  be  fitted  in  the  next  class  of  ship, 
and  on  what  further  work  must  be  undertaken  to  match  this  system  to  the 
propulsion  package  selected  for  that  ship. 
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The  PASS  System 

The  second  major  development  programme  that  was  set  up  was  for  a 
system  known  as  the  Propulsion  and  Auxiliary  Secondary  Surveillance  System, 
(PASS).  The  research  programme  identified  the  need  to  separate  surveillance 
into  2  types: 

(a)  That  needed  by  the  operators  at  their  control  panels  for  normal 

operation  of  the  systems  and  to  carry  out  breakdown  drills,  and  for  the 
safe  reconfiguration  of  the  systems  thereafter. 

(b)  Additional  information  available  to  both  the  operator  and  the  maintainer 
that  need  not,  and  indeed  should  not,  be  permanently  displayed  at  the 
main  panels.  This  requirement  is  the  one  that  is  met  by  PASS  and  is  the 
subject  of  a  later  paper  (Reference  9). 

The  system  is  essentially  a  machinery  surveillance  system  again  using 
distributed  computer  based  techniques  designed  to  gather  a  large  number  of 
plant  parameters  (typically  1000)  and  process  and  display  the  information  using 
Visual  Display  Units  such  that  this  information  is  in  a  readily  assimilated 
format.  The  system  displays  dynamic  information  in  a  hierarchical  structure 
of  "pages"  presenting  information  on  system  schematics,  history  of  parameters, 
maintainer  assist  pages  including  trend  graphs  and  performance  calculations 
and  provides  a  comprehensive  logging  facility. 

The  development  programme  for  the  PASS  system  comprises  a  number  of 
stages.  The  objective  of  Stage  1  is  the  development  of  a  prototype  system  to 
enable  the  operational  and  user  requirements  to  be  fully  evaluated,  and  to 
prove  the  system  design  concept. 

The  approach  taken  to  accomplish  this  objective  was  to  develop  the 
software  on  commercial  hardware,  the  computer  type  being  selected 
principally  on  hardware  availability  and  the  quality  of  software  development 
tools.  As  in  the  Demonstrator  Project,  the  software  is  being  developed  to  be 
transportable  across  computer  types,  and  it  is  therefore  anticipated  that  the 
large  majority  of  the  software  will  eventually  be  used  on  the  final  ship  system. 
This  approach  enables  the  final  selection  of  hardware  for  the  ship  system  to 
be  delayed  for  as  long  as  possible  to  take  advantage  of  the  latest  advances  in 
technology  whilst  also  proving  the  system  concept  functionally  with  low 
development  risk. 

If  the  system  is  approved  for  the  new  Class  of  ship  then  Stage  2  of  the 
development  programme  would  commence  and  involve  the  matching  of  the 
system  to  the  ship  requirements.  Stage  3  would  develop  a  pre-production 
system  using  the  computer  hardware  destined  for  the  ship. 
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Evaluation  Centre 


Experience  with  the  earlier  generation  of  analogue  electronic  systems  when 
first  fitted  in  the  Type  21s  and  Type  42s  had  not  been  satisfactory  and  had  led 
to  many  design  investigations  and  subsequent  modifications.  Recognising  that 
the  problem  arose  largely  from  the  lack  of  a  facility  in  which  to  evaluate  the 
control  system  adequately  before  fitting  it  in  a  warship,  it  was  decided  that 
in  future  all  new  control  and  surveillance  systems  would  be  fully  evaluated  in  a 
purpose  built  Evaluation  Centre. 

This  facility  would  contain  real  time  computer  simulations  of  the  machinery, 
together  with  the  necessary  electronics  to  interface  to  the  control  aud 
surveillance  system  hardware.  It  would  thus  be  possible  to  assess  any  new 
control  concepts  being  introduced  and  to  carry  out  a  comprehensive  evaluation 
of  the  new  systems  before  placing  a  production  order  for  First  of  Class 
hardware.  Quite  apart  from  proving  that  the  system  would  perform  its  actual 
control  functions  satisfactorily  it  would  be  possible  to  investigate  aspects  such 
as  failure  modes,  maintainability  and  operability.  At  a  later  stage  it  would  be 
used  for  the  investigation  of  in-service  problems  and  proposed  modifications. 
This  facility  is  now  operational  and  is  discussed  in  a  companion  paper 
(Reference  11). 

Auxiliary  Control  Systems 

The  current  status  with  regard  to  auxiliary  control  systems  is  that  the 
definitions  of  the  control  tasks  have  all  been  formalised.  However,  it  has  been 
found  that  the  implementation  phase  is  very  dependent  upon  the  actual  ship 
plant,  and  therefore  until  a  ship  has  been  specified  not  much  more  can  be  done. 

It  is  envisaged  that  further  work  would  be  carried  out  during  the  early  stages 
of  an  actual  ship  programme.  There  is  undoubtedly  a  very  close  link 
functionally  and  technologically  between  auxiliary  control  and  the  more 
developed  systems  of  Propulsion  Control  System  and  PASS,  and  therefore  the 
degree  to  which  auxiliary  control  can  be  accommodated  by  or  within  these 
systems  is  being  investigated. 

SCC  Design 

The  design  of  Ship  Control  Centres  can  be  described  as  a  judicious  blend 
of  the  experiences  and  lessons  learned  in  operating  ships  from  centralised 
control  positions,  and  integration  of  the  Propulsion  Control,  PASS  and  NBCD 
system  as  a  co-ordinated  control  centre.  Furthermore  due  cognizance  must 
be  taken  of  the  necessity  to  produce  a  Ship  Control  Centre  which  is  inherently 
safe  to  the  operator  while  at  the  same  time  providing  an  interface  to  the 
computer  which  is  in  a  convenient  form  for  digital  systems,  and  taking 
advantage  of  the  advances  in  ergonomics  and  technology  related  to  displays  etc. 

There  is  currently  no  document  which  helps  in  the  design  of  SCCs  and  so 
it  is  the  intention  to  produce  a  Design  Guide  which  it  is  hoped  will  fill  this  gap. 

Tt  is  also  envisaged  that  much  more  use  will  be  made  of  low  cost  mock-ups 
linked  to  compute*'  simulations  of  the  proposed  plant  to  enable  operator  reaction 
and  the  SCC  design  to  be  assessed. 
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Continuation  Trainers 


Studies  are  being  undertaken  to  identify  the  most  effective  method  of 
carrying  out  follow-up  or  continuation  training  for  machinery  watchkeepers  once 
they  have  left  their  shore  training  establishments  and  gone  to  sea.  From  a  cost 
effective  viewpoint  there  is  a  strong  case  to  be  made  for  using  existing 
equipment  on-board  ship  for  this  task.  A  method  of  achieving  this  would  be  for 
the  ship  to  go  into  local  control  of  the  propulsion  machinery  when  cruising, so 
enabling  the  propulsion  part  of  the  SCC  console  to  be  used  in  conjunction  with  a 
simulation  computer  for  training.  Currently  this  work  is  at  the  feasibility  stage. 


DESIGN  OBJECTIVES  -  HAVE  THEY  BEEN  MET? 

The  Propulsion  Control  System  Demonstrator  is  the  only  system  discussed 
in  this  paper  which  has  progressed  sufficiently  at  the  time  of  writing  to  address 
this  question  to;  but  we  will  see  later  that,  as  a  result  of  lessons  learned,  the 
approach  taken  on  the  PASS  system  is  significantly  different  in  parts. 

Firstly,  looking  at  sofware,  the  design  objective  here  was  to  produce 
software  to  a  high  standard.  It  was  to  be  designed  for  ease  of  documentation, 
testing  and  management;  documented  to  be  maintainable  over  a  life  of  25  years; 
structured  to  be  as  independent  as  possible  of  computer  type  and  intercomputc  r 
communications:  and  flexible  so  as  to  cope  with  modifications  in  service.  Have 
these  criteria  been  met?  Considerable  advances  have  been  made  towards 
meeting  them.  The  quality  of  the  software  to  meet  long  life  standards  is  not  as 
high  as  anticipat'd  and  some  re-work  will  be  required  to  bring  it  up  to  the  full 
standards.  The  strategy  of  software  testing  was  an  area  in  which  some 
difficulty  was  experienced, particularly  as  regards  the  harnesses  required  to 
ensure  that  adequate  re- testing  of  software  was  possible  after  modifications 
had  been  completed.  The  subject  of  software  is  discussed  in  greater  detail  in 
Reference  10  which  concludes  that  considerable  progress  has  been  made  to  meet 
the  high  standards  that  were  set. 

With  regard  to  the  hardware,  the  design  objectives  here  were  basically 
to  produce  to  pre-production  standards,  This  included  full  environmental 
specifications,  MOD  equipment  build  policy  and  standards,  with  nuclear  hardness 
requirements.  The  processor  and  communication  cards  were  supplied  by  the 
computer  manufacturer  but  all  other  cards  had  to  be  developed. 

In  general  all  the  objectives  were  met  except  for  some  problems 
experienced  in  availability  and  delivery  of  a  number  of  highly  specified 
components,  which  resulted  in  concessions  being  given  on  them.  As  regards 
ruggedness  and  nuclear  hardness  requirements,  these  were  met,  but  with  some 
compromises  on  other  targets  such  as  size  of  units.  With  the  benefit  of  hindsight, 
it  may  well  have  been  more  prudent  to  have  specified  a  lower  quality  of  build, 
bearing  in  mind  the  lack  of  experience  which  had  been  obtained  on  the  processor 
type  prior  to  starting  this  Project.  Problems  were  experienced  with  the 
processor  as  regards  its  speed  and  memory  size  and  considerable  additional 
effort  was  expended  in  trying  to  overcome  these  difficulties. 
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The  system  objectives  included  the  requirements,  that  it  should  control 
effectively  a  COGAG  propulsion  plant,  that  it  should  be  easily  installed  on  a 
ship,  and  that  it  should  improve  invulnerability.  It  will  only  be  possible  to 
assess  fully  whether  these  objectives  will  be  met  when  the  Demonstrator 
system  is  delivered  and  undergoes  the  series  of  tests  planned  at  the  Evaluation 
Centres,  but  certainly  the  early  indications  are  highly  encouraging. 

Largely  for  the  reasons  set  out  in  Reference  12,  no  attempt  has  been  made 
during  development  to  achieve  large  reductions  in  manning  levels.  Instead,  by 
reducing  the  amount  of  information  permanently  displayed,  by  automating  the 
logging  of  data  and  by  providing  information  to  the  operators  and  maintainers 
in  a  more  intelligible  form,  the  R.N.  is  in  a  position  for  the  next  class  of  ship 
to: 

(a)  Make  small  reductions  in  the  watchkeeping  crew; 

(b)  Lower  the  qualifications  of  the  watchkeepers; 

(c)  Make  more  effective  use  of  its  manpower. 

Perhaps  one  of  the  most  important  aims  was  to  achieve  a  highly  flexible 
system  that  could  be  readily  adapted  to  take  account  of  changes  in  plant  types. 
Again  it  is  too  early  to  assess  with  complete  confidence  how  far  the  design 
succeeds  in  this  respec^  but  it  is  significant  that  recently,  when  four 
different  propulsion  packages  were  being  considered  in  early  studies  for  a 
new  class  of  ship,  no  undue  difficulties  could  be  foreseen  in  adapting  the 
Demonstrator  or  PASS  systems  to  interface  with  whichever  type  of  plant  was 
finally  chosen. 

Lessons  Learnt 

Even  at  this  stage  in  the  development  of  the  RN  systems,  when  much  work 
remains  to  be  done,  and  with  evaluation  activities  still  at  an  early  stage,  it  is 
possible  to  identify  quite  clearly  some  areas  in  which  a  different  approach 
should  have  been  taken,  and  other  areas  in  which  it  can  be  confidently  stated  that 
the  early  decisions  were  indeed  correct. 

Perhaps  not  surprisingly  it  is  to  the  software  field  that  one  turns  for  the 
first  important  lesson  that  has  been  learnt.  The  software  structure  that  has 
been  derived  for  use  in  these  applications  is  proving  entirely  sound,  and  a 
companion  paper  (Reference  10)  describes  the  steps  that  are  being  taken  to 
ensure  the  reliability  and  maintainability  of  this  software.  The  implementation 
of  the  interprocessor  communications  software  for  the  propulsion  control 
system  has,  however,  not  been  an  easy  task.  The  software  overheads  of  the 
"core",  or  application  independent  software  for  the  system,  as  opposed  to 
the  application  software,  have  been  higher  than  expected,  and  have  led  to 
problems  of  memory  capacity  in  the  hardware  that  was  being  developed 
concurrently. 


A  2-7 


For  the  next  development,  that  of  PASS,  the  decision  was  taken,  as 
explained  in  Reference  9,  to  delay  the  choice  of  ship  system  hardware  until  the 
initial  software  development  had  been  carried  out.  This  enables  the  hardware 
characteristics,  needed  to  host  the  software,  to  be  defined  with  greater  precision, 
resulting  in  a  confident  selection  of  the  ship  system  hardware.  This  latter 
approach  may  very  probably  have  an  associated  penalty  in  terms  of  development 
time,  but  experience  shows  that  this  is  a  price  well  worth  paying. 

A  further  software  problem  that  has  come  to  light  is  the  danger  of 
underestimating  the  task  involved  in  controlling  the  issue  of  software,  and  in  its 
support  and  maintenance  over  the  ship's  life.  Although  many  of  the  tasks  can  be 
done  manually  with  skilled  labour,  it  is  preferable,  on  grounds  of  cost  and 
improved  accuracy,  to  use  a  computer,  where  possible,  and,  indeed,  a 
prototype  system  is  now  being  used  successfully  on  the  PASS  project. 

Probably  two  of  the  most  critical  objectives  in  the  whole  approach  adopted 
by  the  MOD  were  to  achieve  : 

(a)  Software  that  was  transportable,  that  is  that  could  be  run  on  a 

processor  with  a  significantly  different  order  code. 

(b)  Hardware  that  was  application  independent  and  not  tailored  to  a 

particular  machinery  configuration. 

A  foundation  has  been  provided  by  the  software  approach  taken,  which 
makes  it  possible  to  build  on  the  work  already  carried  out  for  future  Machinery 
Control  and  Surveillance  Systems  while  being  able  to  take  into  account  the 
expected  advances  in  hardware  technology. 

The  success  that  has  been  achieved  in  both  the  hardware  and  software 
areas  has  given  the  MOD  considerable  confidence  that  a  far  better  understanding 
of  the  technology  now  exists  and  that  the  main  design  objectives  can,  in  fact, 
be  met. 

Conclusions 

In  designing  systems  for  use  in  warships  the  importance  of  looking  as  far 
into  the  future  as  possible  cannot  be  overstressed.  The  design  on  the  drawing 
board  today  will  probably  be  still  in  service  30  years  or  more  hence,  and  the 
designer  must  therefore  be  bold  in  his  choice  of  the  technology  that  he  intends 
to  use,  or  else  his  systems  will  be  obsolescent  and  generating  significant  support 
problems  long  before  the  end  of  the  ship's  life.  Inevitably  the  use  of  advanced 
technology  throws  up  problems  not  previously  foreseen,  but  provided  the  ground 
is  carefully  prepared,  then  the  rewards  for  striking  the  right  balance  between 
an  approach  that  is  too  adventurous  and  one  that  is  over-cautious  can  be 
considerable.  The  RN  has  opted  to  use  the  microprocessor  in  a  distributed 
configuration  for  the  control  functions  and  to  specify  a  separate  computer  for 
the  secondary  surveillance  function.  Much  work  yet  remains  to  be  done  but 
there  are  no  known  major  barriers  in  the  way  of  achieving  a  powerful  and  highly 
flexible  set  of  machinery  control  and  surveillance  systems  using  this  approach. 
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Figure  A  Refer once  Propulsion  Control  System 
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ABSTRACT 

Based  on  the  premise  that  the  U.  S.  Navy's  primary  needs  in  ship  design  are 
subject  to  various  trade-offs,  the  benefits  to  be  derived  from  state-of-the-art 
automation  technology  are  examined.  A  brief  history  of  naval  machinery  control 
and  operation  is  presented  including  recent  developments  in  technology.  The  role 
of  research  and  development  is  examined  in  relationship  to  satisfying  the  current 
and  future  needs  of  Navy  ship  design.  This  examination  illustrates  the  advantages 
achievable  ir.  the  areas  of  construction,  upgrading,  systems  integration,  decreased 
reaction  times,  manpower  utilization,  equipment  availability  and  information  flow. 
A  digital  data  bus  multiplex  approach  is  discussed  as  a  logical  catalyst  to  effect 
total  shipboard  interface  standardization  for  signal  transmission.  This  approach 
could  bring  about  a  major  beneficial  impact  on  the  way  naval  ships  are  designed 
and  the  way  their  subsystems  are  integrated. 

INTRODUCTION 

During  the  period  since  World  War  11  there  have  been  many  changes  in  the  con¬ 
trol  and  operation  of  both  navy  and  maritime  ships.  For  the  most  part  these 
changes  did  not  start  taking  place  until  the  1960's.  The  major  advances  came  in 
the  merchant  fleet  first*  where  economy  was  a  prime  motivation — profits  were  being 
eroded  by  higher  costs,  mainly  for  manpower.  The  l970's  saw  a  steep  rise  in  these 
advances  as  energy  sources  became  scarce,  which,  coupled  with  inflation,  caused 
significant  increases  in  operational  costs.  The  U.  S.  Navy  was  also  affected  by 
these  forces  and  by  changes  in  personnel  resulting  from  an  all  volunteer  force. 
Reduction  in  manpower  and  more  energy  efficient  operations  became  increasingly 
important  design  goals.  Early  investigations  and  demonstrations  showed  where 
automation  applications  could  help  obtain  the  desired  results.  In  addition,  the 
adoption  of  the  gas  turbine  main  propulsion  plant  made  some  automation  in  these 
areas  mandatory  due  to  critical  equipment  requirements.  However,  U.  S.  Navy 
adoption  of  automation  has  not  been  rapid.  There  are  numerous  reasons  for  this, 
but  high  on  the  list  are  real  concerns  over  reliability  and  standardization,  estab¬ 
lished  maintenance  policies,  damage  control,  military  operational  requirements, 
and  tradition. 

U.  S.  Navy  automation  started  with  the  incorporation  of  an  automatic  steering 
device  which  had  only  limited  success  at  first.  Late  1960  designs  included  direct 
throttle  control  from  the  bridge,  and  by  the  late  1970's  machinery  plant  automation 
was  increased  with  the  use  of  computer  control  and  control  station  monitoring. 
However,  the  equipment  being  produced  actually  represented  early  1970  designs  and 
hardware  due  to  normal  shipbuilding  lead  times.  Results  in  some  cases  were  not 
encouraging  due  to  increased  maintenance  burdens,  and  Increases  in  manpower  and 
skill  levels  to  deal  with  this  "new"  technology.  These  problems  led  some  to  be 
lieve  that  automation  was  required  in  gas  turbine  powered  ships  but  not  desirable 
in  other  ships.  From  an  R&D  point  of  view,  this  was  not  startling  information. 
More  RDT&E  effort  applied  to  the  pre-shipbuilding  phase  would  have  uncovered 
many  problems  before  they  were  built  into  the  ships.  Insufficient  attention  to 
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reliability  and  maintainability  in  early  phases  contributed  to  deficiencies  of 
these  designs  and  accounted  for  much  of  the  problems. 

The  driving  forces  of  increased  costs  of  initial  construction,  manpower  and 
energy,  demands  for  timely  and  reliable  information,  and  operational  survivability 
should  cause  rethinking  in  the  area  of  automation.  New  technology,  processes,  and 
hardware  have  put  a  new  light  on  the  incorporation  of  automation,  where  microelec¬ 
tronics  (with  super  reliability),  modularity  (with  greatly  decreased  maintenance 
requirements),  distributed  control,  satellite  communications,  built-in-test  equip¬ 
ment,  better  personnel  environment,  and  automatic  monitoring  and  trend  analysis 
techniques  will  remove  many  of  the  drawbacks  some  see  in  automation. 

BACKGROUND 

Commercial 

For  many  decades  various  facets  of  industry  have  automated  their  operations 
for  two  main  reasons — economy  and  no  other  way  to  do  the  job.  The  oil,  automo¬ 
bile,  textile,  electronics,  and  chemical  industries  are  excellent  examples  of 
increasing  automation.  Generally,  manual  operations  are  slow,  less  accurate  and 
less  productive  than  automatic  techniques.  Some  operations  like  electroplating, 
microcircuit  manufacturing,  and  gas  turbine  control  cannot  be  done  by  manual  means 
and  therefore  must  be  automated. 

Automation  in  the  marine  industry,  unlike  the  aircraft  industry  which  required 
automatic  and  remote  control  because  of  low  aircraft  manning  levels  and  fast  re¬ 
sponse  requirements,  has  not  progressed  rapidly.  Although  autopilots  were  intro¬ 
duced  in  the  mid-l92G'8  it  wasn’t  until  after  World  War  II  that  they  began  to  be 
in  wider  use.  More  sophisticated  equipment  and  operations  did  not  begin  to  appear 
until  the  1960’s.  These  included  remote  throttle  control,  centralized  engine  con¬ 
trol  room,  unmanned  engine  rooms,  and  the  introduction  of  collision  avoidance 
systems.  The  incorporation  of  these  advances  in  technology  was  motivated  by 
economy — where  profits  were  being  eroded  by  higher  costs,  mainly  for  manpower. 
Fueled  by  inflation  and  scarce  energy  sources,  operational  costs  increased  signif¬ 
icantly  in  the  1970’s  causing  a  steep  rise  in  technology  advances  being  incorpor¬ 
ated  into  ships.  In  1979  the  Third  International  Symposium  on  Ship  Automation 
(ISSCA-79)  was  held  in  Tokyo  where  many  of  the  new  ship  automatic  developments  aad 
applications  were  discussed.  In  these  discussions  it  was  indicated  that  manning 
of  large  merchant  ships  has  been  reduced  to  levels  of  18,  with  some  test  ships 
carrying  only  a  crew  of  12.  For  some  a  goal  of  6  to  10  crew  members  is  being  pur¬ 
sued.  For  the  first  time  a  guideline  report  on  merchant  vessel  bridge  layout 

has  been  prepared  Incorporating  the  latest  in  man-machine  technology *7  Studies 
have  been  made  showing  that  fewer  people  are  required  during  ocean  transit  than 
during  coastal  passage.  This  suggested  crew  reduction  to  6  men  with  shore  based 
crew  when  required.^'  These  studies  indicate  that  highly  automated  navigation 
and  engine  systems  are  required,  with  increased  reliability  over  and  above  present 
levels.  For  ease  of  operation  and  increased  maintainability,  standardization  of 
equipment  and  instruments  is  also  required.  In  addition,  the  studies  also  show 
that  these  projected  small  crews  may  lead  to  loneliness  and  other  mental  conditions 
which  will  require  serious  attention. 

Karasawa^)  surveyed  much  of  today's  merchant  marine  control  systems  and 
Indicated  that  current  unreliable  navigation  equipment  is  being  replaced  by  the 
Navy  Navigation  Satellite  System  (NNSS).  He  said  that  collision  avoidance  systems 
are  absolutelv  necessary;  however,  (if  only  one  vessel  in  an  encounter  has  a  colli¬ 
sion  avoidance  system)  It  Is  only  a  one  sided  assessment  of  the  observed  vessel's 
intended  manuever.  TWo-way  communication  Is  needed  in  order  to  know  the  Intent  of 
the  object  vessel.  He  also  suggests  the  incorporation  of  radio  whistles  and  turn¬ 
ing  direction  Indicators.  The  survey  indicated  the  requirement  for  failsafe  and 
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troublefree  equipment  which  are  readily  maintained.  New  sophisticated  equipment 
requires  upgrading  in  reliability  and  maintainability  due  to  reduction  in  personnel. 

Orito^)  made  some  interesting  observations  relative  to  automation  currently 
being  developed.  He  found  that  standby  engine  room  operation  is  the  most  labor 
intensive  and  must  be  automated  as  much  as  possible.  Condition  monitoring  is 
desirable  and  there  is  a  need  for  improved  reliabitty — this  is  a  prerequisite 
condition.  He  goes  on  further  to  indicate  that  if  the  reliability  of  shipboard 
machinery  on  the  currently  operating  ships  were  adequate,  it  would  be  possible  to 
man  them  with  smaller  complements  without  changing  the  specification  of  the  ships. 
Orito  recommended  improved  reliability  for  auxiliary  systems,  improved  interior 
communications  for  reduced  crew,  automated  navigation,  TV  monitoring  systems,  one 
man  control  wheelhouse,  and  a  collision  avoidance  system.  He  said  that  his  company 
had  a  container  ship  go  to  sea  with  some  of  these  features  in  September  1979. 

Ciundziewicki^^  indicated  that  automation  was  introduced  in  Poland  in  the 
1960's.  They  have  unmanned  machinery  spaces  and  automation  in  100  percent  of  their 
ships  being  constructed  today.  This  includes  engine  room  machinery  control  and 
monitoring  systems,  electrical  power  generation,  auxiliary  systems,  fire  detection, 
bilge  and  watch  control  systems,  and  remote  control  from  the  bridge.  Automation 
will  continue  as  in  the  present,  but  no  expansion  is  expected  since  owners  are  not 
interested.  Some  microprocessors  will  be  used  on  a  limited  basis,  and  as  micro¬ 
processors  make  automation  more  economical  perhaps  the  owners  will  change  their 
minds. 

Other  automation  applications  reported  but  too  lengthy  to  discuss  in  this 
paper  include:  Spain^)— auto  correction  path  monitor;  Turkey^) — collision  avoid¬ 
ance  system;  Russia^®) — anticollision  system  efficiency;  Norway^) — condition  mon¬ 
itoring  here  to  stay,  dual  processing  systems — onboard  and  onshore,  interplay 
between  operator  and  system,  automation  to  assist  man — not  his  master — decisions 
more  for  man;  Gerraany^O) — need  continuous  improvement  in  sensors  for  diesel 
engine  automation;  France(H) — steam  plant  automation. 

Much  of  the  "automation"  that  has  been  reported  involves  installation  of 
collision  avoidance  systems.  These  are  intrinsically  automated  systems  but  they 
do  not  automate  the  process  of  ship  control.  As  presently  designed  and  used  they 
are  only  an  aid  to  the  operator.  However,  depending  on  reliability  and  operator 
acceptance  they  could  make  ship  control  (steering)  an  automated  system — beyond  the 
ability  of  present  day  autopilots.  It  is  significant  to  note  that  there  are  more 
than  seven  worldwide  manufacturers  of  collision  avoidance  systems,  and  as  of 
mid-1981  more  than  1400  systems  were  installed  in  merchant  ships.  Since  the  first 
systems  were  installed  in  1969  there  are  many  thousands  of  ship-years  of  experience 
accumulated.  Operator  confidence  must  be  Increasing  or  new  Installations  would 
fall  off--which  is  not  the  case.  Further  steps  toward  more  automation  are  sure  to 
come. 


Another  extremely  important  area  associated  with  automation  which  is  re¬ 
ceiving  much  attention  from  researchers  and  designers  is  adaptive  systems.  With 
the  advent  of  microprocessors  much  of  this  research  has  now  become  practical. 
At  ISSQA-79.  reports  were  given  on  numerous  applications  of  adaptive  systems. 
Kanaraarud^  discussed  an  adaptive  autopilot  to  reduce  propulsive  energy  con¬ 
sumption  using  simulation.  Anerongen^^'  described  an  autopilot  for  automatic 
trackkeeping  for  bad  weather  which  incorporates  adaptive  feedback.  Horlgome^^^ 
described  an  all  digital  autopilot  which  was  built  and  tested  onboard  a  ship;  this 
system  eliminated  an  extremely  complex  mechanical  system.  Oitsud-*)  reported  on  a 
noise  adaptive  autopilot  tested  at  sea  with  excellent  results. 
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U.  S.  Navy 


The  propulsion  plants  of  U.  S.  Navy  ships  have  been  automated  to  various 
degrees  since  at  least  World  War  II.  Various  level  control  devices  and  automatic 
controls  on  air  compressors  and  distilling  units  have  been  in  use  for  years.  In 
addition,  steam  plants  and  diesel  engines  have  incorporated  various  elements  of 
automation  from  the  beginning. 

The  early  1950’s  saw  the  Introduction  of  pneumatic  automatic  combustion  con¬ 
trol  (ACC)  and  feedwater  regulating  systems.  The  raid-l960*s  saw  the  Introduction 
of  complete  propulsion  plant  automation  systems  for  three  classes  of  600  psi  steam 
turbine  driven  auxiliary  ships:  Amphibious  Cargo  Ship  (LKA  113),  Ammunition  Ship 
(AE  32)  and  Combat  Store  Ship  (AFS  4).  Automation  of  these  auxiliary  ships  re¬ 
sulted  in  remote-operated,  programmed  throttle  control  and  the  centralization 
of  remote  controls  and  data  gathering  necessary  for  plant  operation.  Included  in 
this  design  was  the  extension  of  the  remote  throttle  control  from  the  bridge.  The 
need  for  higher  rated  men,  better  trained  and  more  highly  skilled  for  operation 
and  maintenance  was  clearly  seen  at  this  time.  Cross-training  was  advocated  as  a 
way  to  yield  Navy  personnel  as  much  as  possible  like  their  merchant  marine  counter¬ 
parts. 

As  we  entered  the  1970’s,  higher  automation  levels  continued  with  the  intro¬ 
duction  of  the  steam  driven  auxiliary  ships  of  the  general  purpose  Amphibious 
Assault  Ship  (LHA-1)  Class  and  an  Oiler  (AO-177)  Class.  TWo  new  combatants,  the 
Guided  Missile  Frigate  ( FFG— 7 )  Class  and  Destroyer  (DD-963)  Class,  both  powered  by 
gas  turbines,  followed  in  the  vein  of  the  automated  steam  ships.  This  later  auto¬ 
mation  generally  included  propulsion  unit  control,  throttle  control,  main  reduction 
gear  control,  controllable  pitch  propeller  control,  air  system  control,  fuel  and 
lube  oil  service  system  control,  electric  plant  control  and  data  handling. 

In  late  1976  a  demonstration  of  the  feasibility  of  achieving  a  reduction  in 
bridge  watch  manning  and  improving  surface  ship  readiness  and  operational  effec¬ 
tiveness  was  conducted  onboard  the  Frigate  USS  MCCANDLESS  (FF  1078). This 
demonstration  system  was  designated  the  Integrated  Bridge  System  (IBS).  The  IBS 
embodied  the  integration  of  existing  bridge  equipments  and  the  introduction  of 
automation  into  a  centralized  work  station  for  bridge  watchstanders .  The  IBS 
consisted  of  two  major  consoles  and  peripheral  bridge  and  remote  equipment. 
Incorporated  in  the  system  were  communications  (sound  powered  phones,  ships'  alarms 
manned  and  ready  system,  and  external  voice  communications),  ship  control  (auto¬ 
pilot,  hand  electric  and  non  follow-up  steering  system,  and  a  modified  engine 
order  telegraph — limited  by  the  existing  non-automated  power  plant),  manuevering 
and  navigation  (radar  display,  collision  avoidance,  digital  charting  and  maneu¬ 
vering  board  solutions),  logging  (data  logger,  voice  recorder  and  digital  recorder), 
and  other  Items  such  as  alarms,  an  automatic  Onega  navigation  system,  a  weapons 
advisory  panel,  overhead  centered  pelorus  and  controls  for  all  navigation  lights. 
This  feasibility  demonstration  showed  the  opportunity  for  reduction  of  bridge 
watch  manning  while  maintaining  or  improving  operational  effectiveness  during  the 
evaluation  period  onboard  MCCANDLESS.  However,  incorporation  of  IBS  type  systems 
In  new  0.  S.  Navy  surface  ships  has  not  taken  place. 

A  follow-on  system  to  the  IBS  designated  HICANS  (High  Speed  Collision 
Avoidance  and  Navigation  System)  is  under  joint  development  by  the  U.  S.  Navy 
and  Sperry  Systems  Management  for  the  Guided  Missile  Patrol  Combat  Hydrofoil 
USS  PEGASUS  (PHM-1).  The  HICANS  Is  presently  undergoing  at  sea  testing.  De¬ 
tails  of  this  development  are  discussed  by  Puckett^1^  in  this  symposium. 

Past  Motivation 

The  factors  that  led  to  an  increase  in  automation  were  for  the  most  part 
rather  obvious.  ACC  for  steam  plants  was  being  incorporated  more  and  more  into 
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merchant  ships  with  demonstrated  manpower  savings.  The  U.  S.  Navy  sought  the  same 
economical  benefits.  Automation  also  promised  better  fuel  economy,  faster  re¬ 
sponse,  better  control  and  more  efficient  operation.  The  primary  motivating 
factors  could  be  summarized  into  two  general  categories:  (1)  it  would  be  more 
economical  in  the  long  run,  and  (2)  response  time  required  could  not  feasibly  be 
supplied  by  human  operators.  From  this  evolution  of  shipboard  automation  the  U.  S. 
Navy  finds  itself  in  a  situation  where  some  very  serious  questions  are  being  asked. 

NAVY  AUTOMATION  -  SOME  DIFFICULT  QUESTIONS 

From  the  authors’  viewpoint  it  appears  that  the  U.  S.  Navy  is  questioning  its 
involvement  In  automation  for  a  number  of  practical  reasons.  In  practice  manpower 
savings  are  not  being  realized.  Where  comparison  of  automated  and  nonautomated 
ships  can  be  made,  essentially  no  difference  in  manning  levels  is  evidenced. 
Furthermore,  the  automated  ships  require  a  higher  caliber  of  personnel  with  ex¬ 
tensive  training  to  operate,  troubleshoot  and  maintain  these  more  complex  systems. 
To  date,  these  automated  systems  have  been  more  costly  to  purchase  and  there  is 
mounting  evidence  that  their  maintenance  costs  are  outweighing  their  nonautomated 
counterparts.  With  heavy  maintenance  burdens  being  placed  on  a  limited  number  of 
qualified  personnel,  commercial  vendors  are  being  called  upon  more  and  more  for 
much  of  the  equipment  maintenance,  repair  and  grooming.  When  this  equipment  doesn’t 
function  properly,  it  is  necessary  to  resort  to  the  manual  backup  modes.  Because 
of  the  above  operational  experience,  many  expensive  automated  systems  are  being 
operated  in  an  unplanned  labor  intensive  manual  backup  mode.  Coupled  with  the 
above  manpower  demands  is  the  manpower  required  for  the  ship’s  normal  preventative 
and  corrective  maintenance,  sea  duty,  and  personnel  training.  As  mentioned  earlier 
some  have  raised  the  question  of  "Wouldn't  we  be  better  off  without  automation?" 

It  is  generally  conceded  by  even  the  most  critical  opponents  of  automation 
that  it  does  provide  faster  response,  better  control  and  more  efficient  operation 
when  it  is  functioning  properly.  Nevertheless,  some  of  these  systems  that  have 
been  incorporated  to  date  cannot  be  counted  on  to  be  available  when  needed.  Where 
speedy  response  is  a  critical  requirement,  redundancy  can  be  used  to  provide  suffi¬ 
cient  availability,  but  conventional  redundancy  is  unfeasible  across  the  board. 
Economical  life  cycle  costs  with  all  that  they  entail  (procurement,  operation, 
maintenance,  training,  logistics,  etc.)  together  with  speed  of  response  will  con¬ 
tinue  to  be  prime  automation  motivators  for  U.  S.  Navy  designers. 

Consideration  of  these  prime  motivators  leads  one  to  examine  more  closely 
what  they  entail.  The  increasingly  sophist icated  threat  environment  will  demand 
Increasingly  sophisticated  system  complexity  and  Inter-system  information  exchange. 
More  shipboard  personnel  will  demand  more  information.  Commercial  suppliers  upon 
whom  the  Navy  must  rely  will  be  producing  automated  equipment  to  remain  competitive 
in  the  commercial  arena.  Pressure  from  Industry  to  adopt  increasingly  sophisti¬ 
cated  automated  systems  is  becoming  greater  every  year  as  controls  technology 
advances. Therefore,  the  Navy  will  be  forced  to  select  equipment  from  this 
new  equipment  of  commercial  suppliers  or  purchase  costly  custom  designs.  The  pace 
of  technology  will  increase  such  that  shipboard  equipment  upgrading  will  be  taking 
place  almost  continuously.  The  ships  will  have  to  become  more  survivable  from 
weapons  threats.  There  will  be  a  proliferation  of  sensors,  computers,  communi¬ 
cations  equipment,  electronic  warfare  systems’  countermeasures,  rapid  response 
weapons,  and  navigation  systems  in  future  ships.  These  systems  produce  incredible 
masses  of  data  and  techniques  must  be  devised  to  extract  critical  information 
quickly.  At-Sea  Commanders  must  be  provided  with  capabilities  for  the  automated 
receipt,  storage,  exchange  and  use  of  tactical  data  including  that  from  off-board 
sensors,  in  an  address  to  the  American  Society  of  Naval  Engineers  H.  Tyler 
Marcy,  while  he  was  assistant  Secretary  of  the  Navy  for  R&D,  indicated  the  need  to 
transfer  as  many  of  our  recent  technological  developments  into  our  new  ships  as 
is  possible. (20)  this  address  he  used  the  AEGIS  Combat  System  as  an  example  of 
technology  application  as  a  major  step  forward.  Dr,  Richard  DeLauer^1^)  stated  In 

A  3-5 


an  address  to  the  American  Society  of  Naval  Engineers  that  of  all  the  areas  of 
technology  in  which  the  United  States  has  established  and  demonstrated  its  superi¬ 
ority,  the  area  of  automation  will  almost  certainly  provide  the  greatest  leverage 
on  the  productivity  of  our  military  capabilities.  However,  it  must  be  remembered 
that  the  mission  of  a  Navy  Combatant  ship  is  more  complex  than  that  of  a  commercial 
ship  and  the  consequences  of  unreliability  can  be  much  more  drastic. (21)  Finally, 
will  we  ask  that  the  operation  and  maintenance  of  these  equipments  be  placed  on 
generally  unskilled,  and  overworked  operators/maintainers  whom  the  Navy  can  ill- 
afford  their  time  away  from  the  ship  for  training.  Where  do  we  go  from  here? 

FUTURE  OPPORTUNITIES 

Technological  Applications 

In  a  recent  study^2)  King  concluded  that  consideration  must  be  given  to  the 
substantial  influence  of  computers  in  the  areas  of  monitoring,  controlling,  and 
information  handling.  The  number  of  people  onboard  can  be  reduced  to  a  very  small 
nuraber-the  unmanned  commercial  ship  is  a  practical  possibility  (Une^^  defines 
an  unmanned  ship  as  one  with  6-10  man  crew).  He  also  indicated  that  all  routine 
monitoring  must  be  done  automatically.  He  pointed  out  that  technology  Innovations 
should  enhance  human  capabilities  rather  than  make  them  redundant.  Computers  can 
replace  some  of  the  skills  of  men,  be  a  tool  for  men  to  use,  and  provide  new  tasks 
for  seafarers,  however  there  is  a  need  for  a  greater  awareness  and  understanding 
of  ships  as  soclo-technical  systems. 

Recent  experience  by  the  Royal  Navy^1®)  shows  that  automated  data  handling 
systems  for  track  sorting,  target  identification,  and  routine  processes  involved 
in  compiling  the  tactical  picture  has  acheived  significant  reductions  in  number 
of  men  required  in  the  Operation  Room. 

The  importance  of  the  work  being  performed  in  automatic  control  prompted  the 
holding  of  the  Symposium  on  Ship  Steering  Automatic  Control  in  Genoa  in  June  1980. 
Extensive  theoretical  and  experimental  investigations  of  control,  adaptive  control, 
autopilots,  etc.,  were  discussed  and  published.  Some  of  the  areas  covered  were: 
Hopkins^2-^) — adaptive  autopilot  to  prevent  leeway  where  autopilot  navigates  the 
ship;  Kasahara^n) — optimal  steering  control  systems;  Mcllroy^2^) — reduce  pilot 
workload  with  optimal  control  computer  aided  steering  used  with  precise  navigation 
system;  Coleman^w — adaptive  steering  model  tested  at  sea;  Bouthianon^^ — using 
sophisticated  control  laws  for  the  autopilot  for  the  Tripartite  Mine  liinter. 

Application  of  the  state-of-the-art  in  automation  is  illustrated  by  a  recent 
advertisement  for  an  automatic  steering  system  which  also  works  in  turning  maneu¬ 
vers  and  has  built-in  test  routines  that  do  not  require  knowledge  of  computer 
techniques.  In  addition,  a  joint  venture  of  the  French,  Belgium  and  Netherland 
Navies  involves  Incorporation  of  a  digital  autopilot  for  the  "TRIPARTITE”  Mine- 
hunter  which  uses  sophisticated  control  laws  for  guiding,  piloting  and  controlling. 
The  Imminent  Implementation  of  this  system  can  be  considered  a  significant  applica¬ 
tion  of  shipboard  automation.  (32) »  (33) 

Digital  data  buses  as  embodied  in  the  U.  S.  Navy's  Shipboard  Data  Multiplex 
System  (SDMS)(2®)  and  the  Canadian  Forces*  Shipboard  Integrated  Processing  and 
Display  System  (SHINPADS)(29)  offers  a  capability  that  can  be  exploited  by  permit¬ 
ting  the  incorporation  of  new  automation  technology  by  U.  S.  Navy  ship  designers. 
It  Is  estimated  that  the  DD-963  has  800,000  feet  of  cabling  at  an  Installed  cost 
of  $40/ft.(28)  The  application  of  the  SDMS  concept  is  conservatively  estimated 
to  reduce  the  cabling  installation  cost  oi  a  like  ship  by  35  percent.  That's  a 
savings  of  over  $11  million  per  ship.  Greater  savings  can  be  expected  on  newer 
ship  designs  that  will  undoubtedly  become  more  complex.  Add  to  this  the  benefits 
of  never  having  to  rewire  because  of  installation  of  new  equipment,  changes  in 
threat,  and  new  subsystem  technologies  and  the  cost  savings  continue  to  mount. 


A  major  consideration  in  the  Canadian  Forces  SHINPADS  and  indeed  their  recent 
destroyer  designs  is  the  issue  of  NATO  standardization.  The  work  of  NATO  group 
NIAG  SC  6  regarding  interface  standardization  was  an  integral  part  of  the  SHINPADS 
design.  The  criteria  as  applied  required  all  devices  to  plug  into  the  system  via 
NATO  interfaces  as  proposed  by  STANAG  4153.(30) 

If  we  use  the  analogy  of  SDMS  to  a  conventional  telephone  network  with  the 
appropriate  Interface  terminals  we  get  a  better  idea  of  the  benefits  of  SDMS.  The 
benefits  of  standardization  become  readily  apparent.  Individual  shipboard  equip¬ 
ment  designers  can  proceed  more  at  their  own  pace  with  less  pressure  to  prematurely 
freeze  designs  for  system  integration  because  they  need  only  ’‘plug-in*’  at  standard 
interfaces  at  the  appropriate  time.  Here  again  a  potential costs  savings 
is  realized  by  eliminating  the  need  for  expensive  contract  modifications  after 
detailed  design  begins. 

The  interface  terminals  addressing  the  data  bus  not  only  provide  the  standard¬ 
ization  so  desperately  needed  but  also  provide  for  a  multimission  controller/dis¬ 
play  station.  For  example,  the  same  station  can  function  not  only  as  a  propulsion 
control  unit  but  also  as  a  distilling  plant  energy-conscious  controller  where, 
with  the  push  of  a  button,  its  function  can  change  from  one  to  the  other.  This 
relative  ease  at  reconfigurability  will  provide  post-hit  damage  control  and  equip¬ 
ment  survivability  benefits.  The  information  flow  whether  from  one  compartment 
to  another  or  from  one  end  of  the  ship  to  the  other  is  on  the  common  buses.  In 
fact,  the  greater  majority  of  data  traffic  onboard  the  ship  will  be  on  the  buses. 
Here  again  another  benefit  surfaces.  This  benefit  revolves  around  the  increasing 
demand  for  more  and  more  information  by  more  and  more  parties.  Most  of  the  data 
generated  onboard  will  be  available  on  the  bus  and  inf ormational , display  packages 
can  draw  on  this  data  to  provide  predigested  information  to  whomever  needs  it. 

So  far  most  of  the  prime  motivators  for  automation  have  been  addressed  but 
perhaps  the  question  of  reliability  should  be  further  expanded.  If  the  telephone 
industry  can  make  communications  networks  reliable,  standardized,  modular,  and 
general  purpose  throughout  the  U.  S.  and  the  world,  certainly  the  Navy  should  be 
able  to  do  it  on  one  ship. 

The  U.S.  Navy’s  SDMS  specif ications  require  a  reliability  of  0.999  for  any 
single  user  circuit  that  is  implemented  over  a  24-hour  period.  A  system  reliabil¬ 
ity  requirement  of  0.99999999  over  a  24-hour  period  with  no  repairs  is  also  speci¬ 
fied.^!)  Minimal  mean  time  to  repair  and  applications  of  redundancy  can  further 
enhance  these  design  requirements.  Since  the  SDMS  will  be  a  system  upon  which  all 
subsystems  depend,  it  is  important  that  the  above  reliability  requirements  be 
demonstrated.  Landbased  facilities  are  already  in  existence  to  fully  test  and 
demonstrate  the  SDMS  development  model.  Incorporation  of  a  system,  such  as  SDMS, 
into  ship  design  should  provide  for  almost  limitless  automation  opportunities. 

Certainly  if  industry  wants  to  see  wider  acceptance  of  automation  in  the 
marine  community,  it  will  have  to  assure  that  required  skill  levels  for  operation 
and  maintenance  are  lowered,  that  reliability  is  Increased,  and  chat  mean  time  to 
repair  is  reduced.  The  important  point  is  that  this  is  a  requirement  of  not  just 
the  components  (e.g.,  microcomputers,  integrated  circuits)  but  for  complete  systems 
in  their  final  environment  (relative  location,  temperature,  humidity). 

From  our  viewpoint  the  major  challenge  for  R&D  is  to  make  new  technology 
useful  and  dependable  for  the  ships’  forces.  If  the  automation  isn't  user-friendly, 
we're  just  providing  an  already  overworked  operator  an  additional  heavy  burden. 

R&D  Opportunities 

As  previously  stated  the  prime  automation  motivators  for  the  U.S.  Navy  will 
continue  to  be  life  cycle  costs  and  speed  of  response.  It  should  be  noted  that 
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these  two  areas  encompass:  training,  maintenance,  standardization,  modularity, 
energy  savings,  control  of  complex  systems  and  manpower  (reduction,  skill  level). 
From  an  R&D  viewpoint  these  motivators  represent  opportunities  which  must  be  seized 
to  exploit  automation  for  Its  maximum  benefits.  Four  areas  into  which  these  oppor¬ 
tunities/benefits  can  be  divided  are  as  follows: 

I.  Decreased  response  time  for  situations  where  manual  response  can't  be 
tolerated  or  where  complex  decision/control  processes  are  beyond  human  capabili¬ 
ties.  Modern  weapon  systems  and  the  ships  that  carry  them  must  operate  in  a  fast 
moving  scenario.  Response  times  for  ship  systems  have  become  very  short.  For 
example  automation  is  required  to  operate  and  control  the  main  gas  turbine  propul¬ 
sion  plants  to  carry  out  required  actions  that  are  too  fast  for  response  by  humans. 
Less  than  this  cannot  be  tolerated  or  catastrophic  failures  could  occur.  This 
application  of  automation  will  become  even  more  necessary  if  combined  propulsion 
and  ship  service  electrical  and  electrical  propulsion  systems  (now  being  given 
serious  consideration  by  the  Navy)  are  incorporated  into  new  ship  designs. 

The  exclusive  use  of  voice  methods  to  exchange  information  on  aircraft  car¬ 
riers  is  causing  communications  traffic  to  approach  critical  proportions  between 
work  stations,  especially  during  emergency  conditions.  Officers  are  becoming 
overloaded  and  delays  and  misinterpretation  of  information  due  to  overcrowding 
and  high  ambient  noise  levels  is  becoming  more  common.  In  this  area,  electronic 
methods  to  exchange  information  between  work  stations  could  replace  the  present 
sound  powered,  status-board  method  used  for  exchanging  aircraft  launch  and  recovery 
information,  aircraft  position  information,  weather  and  '’BINGO"  data  and  other 
status  information  affecting  safety  of  operations.  The  associated  record  keeping 
tasks  currently  performed  during  air  operations  and  primary  flight  control  can 
also  be  provided  by  electronic  means. 

A  modern  Navy  ship  is  a  complex  mixture  of  men  and  machinery.  It  is  a  weapon, 
a  hotel  (food,  sleep,  laundry),  a  vehicle,  a  hospital,  a  warehouse,  a  telecommuni¬ 
cations  center  and  a  recreation  facility.  As  such,  the  quantity  of  information, 
record  keeping  and  decision  making  will  require  computers  to  monitor,  store,  sort 
out  and  display  relevant  information  for  timely  decisions.  Systems  will  have  to 
be  developed  that  allow  for  selective  display  of  information,  sharing  of  informa¬ 
tion  among  various  ship  subsystems,  and  the  ability  to  be  interrogated  by  the 
user.  A  major  challenge  to  the  R&D  community  will  involve  fitting  these  machines 
to  the  man  instead  of  vice  versa. 

It  should  be  noted  that  human  operators  by  nature  are  generally  ineffective 
at  monitoring  steady  state  equipment  parameters  and  quickly  become  bored.  At  the 
other  end  of  the  spectrum  the  human  operator  is  subject  to  errors  in  stressful 
situations.  In  addition,  the  human  operator  is  not  ideally  suited  to  environments 
involving  high  heat,  humidity,  noise  or  nuclear  or  chemical  contamination. 

From  the  authors’  point  of  view  the  only  possible  reservation  with  automa¬ 
tion  should  be  that  automated  systems  be  extremely  reliable  with  high  availability 
and  that  the  users/operators  have  confidence  in  the  automated  systems.  Recent 
experience  on  some  systems  has  been  poor  and  the  automated  systems  had  to  be  re¬ 
moved  because  of  lack,  of  availability.  There  is  an  opportunity  here  to  capitalize 
on  technologies  that  are  available  now.  Research  and  development  to  identify 
problem  areas  and  demonstrate  highly  reliable  systems  is  required.  Full  scale 
landbased  simulations  are  required  with  quantitative  techniques  for  measuring 
system  reliability.  System  availability  is  critically  Important  after  the  systems 
are  arranged  in  their  final  ship  configurations. 

Reliability  statistics  In  terms  of  component  failure  rate  data  are  viewed  by 
many  with  much  skepticism.  In  fact,  Dogan^1^  suggests  that  specifying  ultra-high 
reliability  by  MTBF’s  is  inadequate  and  perhaps  probability  of  mission  success 
over  finite  time  periods  would  be  more  meaningful,  especially  on  a  system  basis. 


For  example,  he  indicates  an  Air  Force  digital  avionics  information  system  failure 
rate  of  10“'  failures  per  hour  should  be  stated  as  a  mission  probability  of  suc¬ 
cess  of  .999  999  7  for  a  3  hour  period.  A  commercial  avionics  requirement  of  10"10 
failures  per  hour  in  digital  control  systems  should  indicate  a  success  probability 
of  .999  999  999  for  a  ten  hour  flight. 


Navy  ships  have  longer  mission  times  and  repair  is  possible,  which  confuses 
the  issue  considerably,  but  the  same  concept  could  apply.  It  appears  that  the 
Navy's  task  should  concentrate  not  so  much  on  hardware  reliability  but  on  system 
architecture,  system  software  reliability  and  meaningful  system  reliability  speci¬ 
fications. 


II.  Standardization,  modularity,  and  multipurpose  interactive  displays  with 
access  to  any  and  all  data  to  simplify  the  man-machine  interface  problem.  Some  of 
the  major  problems  today  and  projected  in  the  future  are  high  acquisition  costs, 
high  maintenance,  and  high  skill  levels  required  of  operators  and  maintainers. 
With  the  advent  of  microelectronics  and  digital  technology,  a  large  variety  of 
electronic  operations  can  be  modularized,  and  standardized  assemblies  are  being 
made.  Efforts  are  also  underway  to  establish  the  requirements  for  mechanical 
modularity  and  standardization.  Standardized,  modular  systems  will  reduce  the 
cost  of  spares,  simplify  maintenance  procedures,  reduce  the  cost  of  maintenance 
because  the  number  of  different  components  are  reduced,  and  reduce  skill  level 
requirements  because  modularity  will  permit  many  more  repairs  by  replacement. 
Standardization  and  modularity  should  lead  to  increased  reliability  and  decreased 
maintenance  burden,  and  thus,  provide  the  needed  increase  in  availability. 

The  automation  opportunities  afforded  the  Navy  in  this  area  will  depend  heav¬ 
ily  upon  the  incorporation  of  a  standardized  digital  data  bus  multiplex  system, 
such  as  the  U.S.  Navy*s  SDMS  or  the  Canadian  Forces'  SHINPADS.  Once  this  system 
and  its  interface  modules  are  standardized,  multipurpose  displays  and  controllers 
can  be  standardized.  Research  and  development  efforts  will  be  required  to  assure 
flexibility  is  maintained  In  these  standardized  displays  and  controllers.  The 
multipurpose  aspect  will  require  shipwide  analyses  of  the  multipurpose  functions 
required.  One  approach  could  be  retaining  flexibility  in  software  while  committing 
the  hardware  to  standardization. 

Great  care  should  be  taken  as  to  how  much  information  is  displayed  at  one 
time,  since  human  operators  have  limited  capability  for  asslmulating  information 
and  can  quickly  become  overloaded.  Multipurpose  visual  display  units  can  be  used 
to  display  what  Is  desired  or  required.  For  example,  an  operator  monitoring  the 
status  of  the  propulsion  and  steering  functions  may  not  want  to  know  main  bearing 
temperatures,  lube  oil  temperatures  and  pressure  or  vibration  levels  when  every¬ 
thing  is  working  properly.  However,  when  a  fault  condition  occurs,  this  informa¬ 
tion  could  become  vital.  Equipment  is  available  today  to  perform  this  function. 

Digital  display  systems,  both  electronic  and  solid  state  permit  operator 
interaction  in  order  to  allow  for  multipurpose  information  access  on  all  systems. 
The  displays  can  provide  information  for  decision  making  and  also  be  used  as  a 
control  input  device. 

Research  and  development  efforts  are  needed  to  evaluate  the  benefits  and 
point  the  way  for  shipboard  applications  in  such  areas  as  using  color  for  displays, 
bright  screen  displays  for  bridge  use,  making  displays  multipurpose  but  simple, 
and  developing  a  maintenance  philosophy  based  on  standardization  and  modularity. 

III.  Cost  effective  redundancy  achievable  through  distributed  control.  Pres¬ 
ent  technology,  mainly  as  a  result  of  highly  reliable  and  relatively  inexpensive 
microprocessors,  involves  a  variety  of  applications  of  distributed  control  through¬ 
out  industry.  It  is  possible  to  design  standardized,  modular  processors  inexpen¬ 
sively,  permitting  their  widespread  application  in  different  systems.  In  addition 
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redundant  systems  can  be  designed  in  order  to  maintain  high  system  availability  in 
the  event  of  a  casualty.  This  will  permit  using  alternate  paths  inherent  in  a 
distributed  control  system  to  circumvent  failed  or  damaged  equipment.  The  navies 
of  several  countries  are  investigating  the  use  of  these  distributed  systems.  This 
is  an  opportunity  that  doesn't  have  to  be  made  or  found.  It  is  here.  However, 
research  and  development  will  be  necessary  to  implement  the  most  cost  effective 
options  to  suit  Navy  missions.  Coupled  with  data  bus  techniques  new  concepts 
should  consider  this  new  technology  to  reduce  costs  of  redundant  systems,  provide 
more  system  flexibility,  and  provide  the  ability  to  reconfigure  for  casualty 
control. 


IV.  Non-interference  onboard  training  of  the  crew  accomplished  both  at  dock- 
side  and  underway.  As  a  result  of  the  availability  of  inexpensive  microcomputers, 
digital  simulation  techniques,  and  multipurpose  interactive  displays  new  and  effec¬ 
tive  training  tools  are  available.  At  dockside,  using  simulated  scenarios  the 
ship  can  be  made  to  appear  to  perform  many  emergency  and  out  of  the  ordinary  opera¬ 
tions  and  provide  for  non-interference  training.  Training  rooms  can  be  made  avail¬ 
able  with  interactive  displays  to  provide  a  continuous  learning  capability.  Even 
while  at  sea,  the  simulation  techniques  can  be  used  to  train  the  crew  in  many 
types  of  emergency  situations  both  in  the  machinery  and  bridge  areas.  Encompassed 
in  the  computer  data  base  can  also  be  the  step-by-step  troubleshooting  and  mainte¬ 
nance  instructions.  The  opportunities  here  appear  to  be  boundless.  Development 
of  new  training  philosophies  and  evaluating  new  training  on  simulators  is  required 
to  make  optimum  use  of  this  capability. 

CONCLUSION 

It  was  the  intent  of  this  paper  to  present  an  R&D  perspective  of  the  automa¬ 
tion  opportunities  available  to  the  U.S.  Navy.  The  picture  that  materializes  is 
one  of  complexity,  rapid  change  and  diversity.  As  can  readily  be  inferred  from 
the  foregoing  examples  of  the  many  R&D  automation  ’’products"  being  generated, 
there  appears  to  be  an  endless  supply.  The  fact  remains,  however,  that  this  tech¬ 
nology  push  doesn't  always  line  up  with  the  requirements  of  the  normally  conserva¬ 
tive  buyer. 

The  major  challenge  to  the  R&D  community  appears  to  be  developing  a  more 
effective  methodology  for  phasing  new  technology  developments  into  long  term  devel¬ 
opment  requirements.  In  other  words,  increased  attention  has  to  be  paid  to  a 
more  focussed  automation  technology  procession  by  the  R&D  community  in  order  that 
Navy  ships  of  the  future  will  be  both  cost  effective  and  mission  worthy. 
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INTRODUCTION 

In  this  article  some  critical  remarks  are  made  about  the  design 
and  application  of  ship  control  systems.  Firstly,  the  criteria  for 
the  application  will  be  discussed.  Secondly,  the  sequence  of  the 
various  steps  in  the  design  phase  are  investigated.  Thirdly,  the 
research  in  relation  to  the  complexity  of  the  system  is  discussed 
including  the  status  quo  in  the  Netherlands. 

CRITERIA  FOR  APPLICATION 

Before  a  decision  about  the  application  of  a  control  system  on  board 
ships  can  be  taken,  five  criteria  have  to  be  considered: 

-  Does  the  application  improve  the  working  conditions  of  the  man 
on  board? 

-  Does  the  application  lead  to  a  more  efficient  use  of  the 
available  manpower? 

-  Does  the  application  improve  the  availability  of  the  ship? 

-  Does  the  application  decrease  the  maintenance  cost  of  the  ship? 

-  Does  the  application  decrease  the  operational  cost  of  the  ship? 

The  authors  strongly  believe  that  criteria  for  the  application  of 

a  "beautiful  control  system"  have  sometimes  been  contrived  to  enable 
the  application  of  a  newly  developed  control  system.  The  decision  to 
apply  a  control  system  should  not  be  taken  before  the  advantages  of 
the  application  of  the  system  are  obvious. 

DESIGN  SEQUENCE 

To  obtain  an  optimal  ship  control  system  much  effort  should  be 
put  into  the  management  of  the  designers.  The  science  of  control 
engineering  is  a  relatively  new  one,  so  some  rather  important  steps 
that  should  be  taken  in  the  right  order,  are  sometimes  taken  too  late 
or,  some  steps  are  even  totally  neglected. 

Ten  different  steps  that  should  be  taken,  can  be  seen;  the  correct 
order  of  the  steps,  however,  depends  on  the  nature  of  the  system  to 
be  designed. 

The  objectives,  including  the  essential  data. 

Although  it  sounds  simple  to  establish  the  objectives  and  the 
essential  data,  it  is  very  often  the  most  complicated  phase  of  the 
design  process.  The  objectives  should  be  optimalized  in  order  to  get 
a  cost  effective  system.  Collection  of  the  essential  data  is  not 
complicated;  the  main  problem  is  to  distinguish  which  data  are  essential. 


Modelling  of  the  control  system. 

In  order  to  design  an  optimal  control  system,  a  model  of  the 
system  is  indispensable.  The  design  philosophy  of  the  control  engineer 
and  the  professional  engineer  (naval  architect,  electrical  engineer, 
etc.)  differ  a  lot.  It  is  generally  accepted  by  scientists,  who  are 
not  involved  in  control  engineering,  that  a  mathematical  model  can  be 
very  complicated.  The  control  engineer  though  generally  settles  for  a 
simple  "black  box"  model,  which  usually  turns  out  to  be  adequate. 

Simulation  and  sensitivity  study. 

As  soon  as  the  mathematical  model  of  the  process  and  the  control 
system  have  been  established,  the  process  can  be  simulated.  The 
sensitivity  of  the  various  co-efficients  should  be  investigated,  to 
detect  which  co-efficients  can  be  neglected. 

Requirements . 

The  requirements  can  be  obtained  from  the  simulation  study  to 
make  the  system  as  cost  effective  as  possible,  the  requirements  should 
be  limited  to  the  absolute  minimum. 

Market  analysis. 

Many  control  engineers  tend  to  prefer  to  design  their  own  special 
purpose  control  system  as  opposed  to  buying  a  general  one.  As  a  result 
the  system  applied  is  very  often  more  expensive  than  a  general  purpose 
system,  and  it  is  also  more  complicated  to  service. 

A  thorough  market  analysis  should  be  considered  together  with  the  fact 
that  a  general  purpose  system  often  will  be  less  expensive  than  a 
specially  designed  system. 

Prediction  of  -  investment 

-  operating  cost 

-  effectiveness 

-  reliability 


These  four  items  define  the  final  success  of  the  application  of 
the  system. 

Production  and  installation  of  prototype. 

Checking  of  performance. 

The  performance  should  be  checked  and  compared  with  the  mathemat¬ 
ical  model,  the  simulation  and  with  the  prediction. 

Final  production  and  installation. 

Continuous  analysis  of  the  system. 

During  the  operation,  the  system  should  be  checked  continuously, 
to  gather  the  necessary  information  for  improvements  to  future  systems. 
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THE  RESEARCH  IN  RELATION  TO  THE  COMPLEXITY  OF  THE  SYSTEM. 


Scanning  through  the  papers  of  all  the  ship  control  systems 
symposia,  including  this  6th  SCSS,  it  is  noticeable  that  almost  all 
papers  are  dealing  with  sub  systems. 

This  may  seem  remarkable,  but  indeed  it  indicates  the  trend  in  ship 
control  research.  Research  in  sub  system  control  subjects  seem  to  be 
popular  and  of  interest  to  the  researcher.  The  fleet  manager,  however, 
ought  to  realize  that  research  into  fleet  control  and  so  into  integrated 
systems  is  more  effective.  Nowadays,  a  tremendous  amount  of  effort  is 
spent  relatively  on  sub  system  control,  but  little  effort  is  put  into 
4  the  control  of  the  whole  ship  and  the  effort  spent  on  the  control  of 

j  a  whole  fleet  is  almost  negligeable. 

Let  us  glimpse  now  at  the  status  quo  regarding  ship  control 
systems  research  and  application  in  the  Netherlands. 

Before  presenting  you  this  picture,  it  is  perhaps  good  to  realize 
>•  that  in  the  Netherlands  also,  the  development  of  technology  is  greatly 

‘  affected  by  our  fast  changing  society  and  the  consequences  of  the 

f  drastic  changes  in  energy  policy  since  the  1973-crisis. 

■  In  ships  of  the  Royal  Netherlands  Navy  and  the  Merchant  Navy  more 

and  more  control  systems  are  applied  as  a  result  of  the  technology 
\  push  and  the  push  is  reducing  ship's  crew  members. 

However,  a  certain  reluctance  to  use  more  and  more  automation  can  be 
observed,  especially  in  the  Merchant  Navy,  as  reliability  of  control 
systems  on  board  seagoing  ships  still  seems  too  poor. 

Of  course  manufacturers  of  ship  control  systems  claim  that  their 
system  is  very  reliable,  but  practice  shows  different  results.  Also, 
quantifying  figures  are  very  difficult  to  obtain  especially  regarding 
mechanical  components. 

The  Navy  is  still  launching  a  new  generation  of  GT-frigates. 
Development  and  design  of  the  control  systems  of  these  ships  are  in 
the  final  production/installation  and  "feed  back"  stage.  Efforts  are 
now  focussed  at: 

-  amelioration  of  and  integrating  the  sub  systems 

-  standardising  and 

-  computerising  the  operational  availability  of  a  total  ship  and 
fleet . 

As  far  as  the  Merchant  Navy  is  concerned,  a  milestone  was  reached 
in  1979.  At  that  time  the  government,  shipowners,  shipbuilders  and 
Union (s)  -as  participants  in  the  organization  of  the  Netherlands 
Maritime  Institute-  initiated  the  so  called  "Ship-80  project".  The 
main  objective  of  this  project  is:  "to  draft  directives  for  the  design 
of  rationalised  ships  for  the  1980's". 

The  rationalization  is  specifically  aimed  at  the 

-adaptation  of  the  number  of  crew  members  to  the  changing  economic 
and  social  circumstances 
-minimizing  and  control  of  maintenance 

-minimizing  energy  needs  of  the  ship  and  its  sub  systems 
-minimizing  production  and  shipbuilding  costs. 

The  project  will  be  completed  by  the  end  of  1981  and  is  divided 
in  two  phases.  About  175  spec  alists  (mainly  part-time)  are  involved 
in  the  realization  of  the  project.  The  approach  is,  in  our  opinion, 
rather  new:  a  total  integrated  systems  approach. 
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Figure  1.  shows  the  working  scheme  of  the  project.  Three  lines  can  be 
identified,  namely  a  technical  one,  an  operational  one  and  a  financial/ 
economical  one.  To  realize  the  technical  analysis  the  ship  has  to  be 
divided  in  modules  (sub  systems) .  At  the  end  all  the  studies  have  to 
be  integrated.  Up  to  date  experiences  indicate  that  a  number  of  tools 
we  have  to  work  with,  are  not  adequate  enough.  The  reason  is  obvious: 
science  of  a  number  of  branches  for  the  shipping  industry  is  still  at 
an  inadequate  level. 

Research  institutes  and  universities  in  the  Netherlands  are 
working  on  problems  mainly  associated  with  sub  systems.  For  example: 
ship  manoeuvring,  motion  control,  vessel  traffic  in  harbours, 
propulsion  machinery,  all  using  mathematical  simulation  models. 

Adaptive  autopilots  and  application  of  human  engineering  are  also  still 
subjects  of  research. 

In  conclusion,  it  must  be  stated  that  there  is  a  tendency  to  look 
more  and  more  into  the  direction  of  the  control  of  the  integrated 
system. 


The  general  situation  regarding  ship  control  systems  research 
efforts  can  be  visualized  in  figure  2a,  b,  and  c. 

From  figure  2  can  be  derived  that  too  much  effort  is  spent  on 
the  sub  systems.  Research  into  sub  systems  is  not  as  complicated  as 
research  into  the  integrated  system.  It  should  not  take  years  before 
a  useful  result  can  be  achieved.  It  should  also  be  realised  that  it 
is  much  more  effective  to  increase  the  reliability  of  an  integrated 
system,  i.e.  a  whole  fleet  than  to  increase  the  reliability  of  all 
the  different  components  of  the  fleet. 

As  can  be  seen  from  the  status  quo  of  ship  control  systems  in 
the  Netherlands,  the  Navy  and  those  who  are  involved  in  shipping 
industry,  -in  a  modest  way-  are  trying  to  fill  the  above  mentioned 
gap  in  research. 

CONCLUDING  REMARKS 

Supposing  that  the  presented  papers  and  publications  of  ship 
control  systems  are  representative  for  the  direction  and  speed  of 
advance  in  this  field,  it  must  be  stated  that  the  results  of  15-20 
years  of  research  are  rather  poor.  We  have  to  keep  in  mind  that 
technology  has  to  anticipate  the  fast  changing  structures  and  demands 
in  society.  This  can  only  be  solved  by  thinking  in  conceptions  of 
developments  of  systems. 

So  the  authors  are  of  the  opinion  that  much  more  effort  should  be 
spent  in  research  in  integrated  systems  -  there  is  little  time  to 
fulfill  this  goal. 
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Figure  1.  Working  scheme  project  "Ship-80" 
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Figure  2 . 
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MACHINERY  MONITORING  SYSTEMS 


by  M.J.  Curran, 

Hawker  Siddeley  Dynamics  Engineering  Ltd. 


j  ABSTRACT 

A  distributed  microprocessor  machinery  monitoring  system  has  been 

designed  and  built,  tailored  to  significantly  reduce  the  watchkeeping 
task  in  the  machinery  spaces  of  naval  vessels.  The  structure  of  the 
evaluation  system  is  outlined  indicating  the  operational  advantages  to 
i  the  watchkeeper.  The  lessons  learnt  from  design  and  development  of 

'  this  evaluation  system  are  examined  and  a  revised  system  is  described 

!  which  uses  the  experience  gained.  Finally,  the  manner  in  which  the 

1  collated  data  at  the  central  station  can  be  used  in  terms  of  Health 

!  and  Trend  analysis  are  reviewed. 

j  Introduction 

The  machinery  Monitoring  Systems  dealt  with  in  this  paper  were 
j  developed  in  response  to  a  Statement  of  Requirements  for  a  Group  Warn- 

\  ing  System. (Ref  1),  as  part  of  an  overall  contract  from  the  Ministry 

<  of  Defence  (Procurement  Executive).  The  original  hardware  concept  was 

\  based  upon  maximum  commonality  with  the  Distributed  Control  System, 

s  which  forms  the  subject  of  a  separate  paper  at  this  Symposium  (Ref  2). 

|  Both  of  the  systems  described  are  specifically  configured  to  meet 

the  requirements  imposed  by  conditions  existing  in  machinery  spaces. 
However,  this  attribute  makes  such  systems  ideally  suited  to  any  moni¬ 
toring  application  when  physical  size,  high  ambient  temperature  and 
dirty  environmental  conditions  preclude  the  use  of  "standard  commer¬ 
cial"  systems. 

In  this  paper,  the  general  topic  of  monitoring  systems  will  be 
dealt  with  in  four  parts. 

(a)  The  Group  Warning  System  Concept. 

(b)  The  Evaluation  System  produced  for  Vickers  Shipbuilding 
Group  Ltd. 

(c)  The  lessons  learnt  from  the  Evaluation  System  and  present 
developments. 

(d)  The  indirect  benefits  gained  from  the  ability  to  carry  out 
Health  and  Trend  analysis. 

The  direct  benefits  gained  from  the  installation  of  any  distri¬ 
buted  monitoring  system  in  terms  of  reduced  manning  levels  and  lower 
installation/cabling  costs  have  been  well  aired  in  earlier  symposiums. 
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The  Group  Warning  System 

The  concept  for  the  Group  Warning  System  evolved  out  of  the  need 
to  reduce  the  numbers  of  crew  now  involved  in  watch  keeping  tasks  in 
machinery  spaces.  The  basic  hardware  structure  is  based  upon  time 
proven  data  logger  principles.  The  "System"  differs  from  data  loggers 
in  two  important  aspects.  (Fig.l) 

(a)  The  data  collection  from  the  source  transducers  is  con¬ 
figured  around  the  use  of  distributed  microprocessors,  which  in 
addition  to  the  data  collection  function,  provide  the  ability  to 
compare  input  values  with  preset  limits  and  generate  warning 
flags  for  those  channels  exceeding  the  limits. 

(b)  The  data  from  all  input  channels  is  collected  at  a  single 
point  and  collated  into  Machinery  Groups.  This  is  where  all 
signals  related  to  a  single  piece  of  plant,  regardless  of  their 
geographic  origins,  are  collated  to  drive  a  single  back  lit 
legend,  termed  a  Warning  Window.  Thus  in  the  event  of  any  plant 
malfunction,  the  watchkeepers  attention  is  immediately  drawn  to 
the  relevant  system.  Back  up  information  in  terms  of  the  actual 
parameter  and  its  value  against  its  limit  is  simultaneously  pro¬ 
vided  on  a  VDU .  Secondary  benefits  are  that  the  watchkeeper  may 
view  the  current  value  of  any  parameter  without  moving  from  his 
position  and  that  all  warnings  are  logged  automatically  relieving 
the  operator  of  this  monotonous  chore.  Inhibit  facilities  to 
prevent  unwanted  warnings  from  shut  down  plant  or  faulty  trans¬ 
ducers  are  also  provided. 

The  Evaluation  System 

The  basis  of  any  distributed  monitoring  system  is  a  Central 
station,  or  Master  unit,  and  an  outstation  which  is  repeated  to  match 
the  number  of  channels  it  is  desired  to  monitor,  and  their  geographic 
locations.  The  primary  requirements  for  the  Evaluation  System  are 
shown  in  Table  1. 


1> 

Table  1  System  Requirements 

1000  input  channels. 

2) 

1  second  update  rate  for  all 

channels. 

3) 

Integral  signal  conditioning 

for  standard  hardware 

4) 

Multiple  fallback  modes. 

5) 

Structured  software. 

6> 

Nuclear  hard  capability. 

7} 

Extended  temperature  operation. 

8) 

Rugged  construction. 

An  Overview  The  hardware/software  structure  of  the  Evaluation 
system  was  based  upon  the  work  done  on  the  development  of  the  Digital 
Distributed  Control  and  Surveillance  System  (Reference  2), 
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GROUP  WARNING  SYSTEM  CONCEPT 


Serial  Data  Dink 
To  optional  surveillance 


Plant  Inputs 
(100  Max  1 


The  Central  Station  provides; - 

1)  Correlation  of  channels  in  to 
Machinery  Groups. 

2)  Operator  "alert"  for  any  channel 
exceeding  its  limits. 

3)  The  operator  with  full  information 
about  the  channel  in  warning. 

4)  The  ability  to  view  the  current 
value  of  any  channel. 


The  Outstation  provides:- 

1)  Full  signal  conditioning  for  100 
inputs . 

2)  The  scaling  of  inputs  into  engin¬ 
eering  limits. 

3)  The  comparison  with  preset  limits 
and  warning  generation  where 
required . 

4)  The  facility  to  inhibit  unwanted 
warnings  for  example  from  disconnected 
transducers . 

5}  The  final  fall  back  position  for  the 
operator  in  the  event  of  failure  of 
other  parts  of  the  system. 


Figure  1  .  Group  Warning  System  Concept 


The  hardware,  comprising  a  set  of  electronic  plug-in  modules,  has 
been  designed  for  operation  in  ambient  temperatures  of  up  to  LOOdeg  C 
and  to  withstand  the  shock  levels  which  may  be  experienced  in  Naval 
environments.  All  devices  chosen  in  the  design  of  these  modules  have 
been  selected  to  ensure  that  the  system  as  a  whole  is  resistant  to  the 
radiation  levels  likely  to  be  experienced  in  a  tactical  environment. 

In  order  to  ensure  the  maximum  flexibility  of  the  hardware,  the 
computer  bus  configuration  was  adopted  whereby  all  of  the  interface 
modules,  whether  they  be  plant  interface  or  serial  data  links  to  other 
processors,  are  connected  directly  to  the  computer  highway. 

The  data  links  used  for  the  transmission  of  data  from  the  outsta- 
tions  to  the  central  station  are  high  integrity,  high  speed  serial 
links  using  the  Ferranti  Serial  Signalling  System  protocol.  These 
data  links  are  star  connected  for  maximum  overall  system  reliability 
without  recourse  to  the  complication  of  duplicated  links. 

The  software  used  in  the  system  is  fully  modular,  running  under 
the  MASCOT  operating  system.  The  software  has  been  split  into  two 
parts.  The  Systems  and  the  Applications  code.  Whilst  this  causes  some 
increase  in  the  overheads,  and  therefore  the  software  runtime,  this 
gives  the  advantages  that  the  system  may  be  configured  to  a  new  appli¬ 
cation  by  merely  compiling  new  sets  of  parameter  tables. 

Further  details  of  the  hardware  and  software  formats  can  be  found 
in  reference  2. 

The  Outstation  The  outstation  comprises  five  modular  units 
(fig. 2)  mounted  in  a  cabinet  of  l2u  (  21  inches)  height.  These  units 

are ; 


(a)  The  card  frame  containing  all  of  the  electronic  modules. 
These  modules  cover  the  functions  of  the  processor,  volatile  and 
non-volatile  memory,  serial  data  link,  and  all  signal  input  and 
display  output  functions. 

(b)  The  filter  unit  which  provides  full  Radio  Frequency 
Interference  and  Electro  Magnetic  Pulse  protection  for  approxima¬ 
tely  280  input  lines,  with  a  plug  break  between  the  filter  unit 
and  the  ships  cabling.  This  plug  break  allows  the  outstation  to 
be  installed  much  later  than  is  normal  in  the  vessel  build 
program,  after  all  of  the  ships  cabling  and  transducers  have  been 
installed  and  checked. 

(c&d)The  Transformer/Rectifier  Unit  and  the  Power  Supply  Rack.  A 
440V  3  phase  supply  is  used  to  gain  the  advantaoe  of  transformer 
isolation  without  the  bulk  of  smoothing  components  associated 
with  the  use  of  a  single  phase  supply  at  the  required  current 
ratings.  The  power  supply  rack  provides  the  necessary  d.c. 
voltage  rails  with  over  voltage/under  voltage  protection  and  the 
cooling  fans. 

(e)  The  Man  Machine  Interface  unit,  (Fig. 3  )  which  in  addition 
to  providing  the  Operator  with  the  final  fall  back  position,  in 
the  event  of  a  data  link  or  central  station  malfunction,  also 
provides  the  Maintainer  with  the  ability  to  reconfigure  channels 
to  match  in-service  requirements.  This  may  be  achieved  at  short 
notice  and  without  specialist  help.  The  important  operator 
facilities  provided  locally  to  each  outstation  are; 
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i)  Indication  of  any  channel  going  -nto  warning. 

Li)  The  ability  to  accept  any  channel  in  warning, 

iii)  The  ability  to  view  the  current  value  of  any  channel, 

iv)  The  ability  to  view  the  upper  and  lower  warning  limits  of 

any  channel. 

In  addition,  the  following  facilities  are  available  to  the  Main- 

tainer.  These  maintainer  facilities  are  operated  via  key 

switches,  preventing  unauthorised  changes. 

v)  The  ability  to  alter  the  scaling  of  any  input  channel, 

vi)  The  ability  to  alter  the  upper  and  lower  warning  limits, 

vii)  The  ability  to  inhibit  any  channel.  This  is  to  prevent 

unwanted  warnings  where  a  transducer  is  disconnected  and/ 
or  faulty. 

The  five  units  being  modular,  are  capable  of  being  independently 
tested.  Using  the  card  frame  as  the  star  point  all  the  modules  are 
plug  connected  using  one  to  one  cables. 

Central  Station  The  hardware  for  the  central  station  is,  as  far 
as  possible,  identical  with  that  used  for  the  outstations.  The  prin¬ 
ciple  differences  are  the  addition  of  the  Group  Warning  Windows  and 
VDU  for  the  primary  display  and  a  unique  MMI  panel  reflecting  the 
functional  task  of  the  central  station. 

The  Experience  Gained 

The  most  important  outcome  of  the  Evaluation  system  has  been  the 
reception  it  has  been  given  by  the  Machinery  Watchkeepers  who  have  had 
the  opportunity  to  see  the  system  in  operation.  In  spite  of  some 
shortfall  in  the  performance  of  this  system,  all  those  concerned  with 
the  creation  of  the  "Group  Warning  "  concept  are  convinced  that  the 
philosophy  is  sound. 

This  evaluation  system  has  demonstrated  very  clearly  the  penalties 
incurred  by  the  requirement  for  nuclear  hard  electronics.  In  essence, 
to  meet  the  specified  radiation  levels,  the  choice  of  semiconductor 
devices  was  limited  to  those  fabricated  using  bipolar  technologies. 
Since  the  number  of  transistors  per  chip  is  typically  7000  for  bipolar 
compared  with  over  50,000  for  MOS  fabrication  techniques,  then  it  is 
readily  apparent  that  the  use  of  bipolar  technology  severely  limits 
the  amount  of  "intelligence"  per  ch  ’  r.  available  in  the  system.  This 
situation  is  dramatically  compounded  when  the  range  of  support 
devices,  such  as  USART'S  etc.  is  considered.  This  results  in  poor 
system  performance  per  unit  cost  when  compared  with  MOS  systems. 

This  limitation  of  component  choice  also  has  a  major  impact  on  the 
design  and  layout  of  the  hardware  with  a  very  high  component  count  per 
function  necessitating  sophisticated  high  current  power  supplies  and 
distribution  systems.  Another  effect  of  bipolar  devices  is  that  the 
very  high  edge  currents  demand  the  use  of  multilayer  PCBs  with  corres¬ 
ponding  cost  and  production  timescale  effects. 
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The  evaluation  system  was  configured  for  maximum  flexibility  with 
all  I/O  modules  interfacing  directly  with  the  computer  bus.  (Fig. 4) 
This  arrangment  permits  all  system  changes  to  be  made  in  software. 

With  hindsight,  this  arrangement  has  resulted  in  maintainability 
problems,  in  spite  of  the  extensive  error  reporting  software  and  hard¬ 
ware  status  indicators.  In  practice,  it  has  been  found  that  the 
majority  of  system  failures  have  been  difficult  to  isolate  and  inden- 
tify,  as  they  often  involve  a  processor  crash  which  renders  diagnostic 
software  useless,  and  therefore  require  skilled  personnel  and 
sophisticated  test  equipment. 

The  emphasis  on  generality  and  configurability  in  the  software 
structure  has  resulted  in  cumbersome  background  tasks  generated  by  the 
operating  system  overheads.  When  compounded  with  the  heavy  traffic 
conditions  on  the  data  links,  and  the  comparativly  low  amount  of 
processing  power  available  in  the  bipolar  CPU,  the  system  response 
falls  below  the  exacting  requirements  of  this  configuration,  although 
very  little  software  tuning  has  yet  been  carried  out. 

The  Man  Machine  Interface  design  was  successful  in  that  once  a 
prospective  operator  had  been  familiarised  with  the  system,  the  opera¬ 
tion  of  the  system  via  the  MMI  was  largely  self  evident.  However,  the 
panel  is  dedicated  to  its  present  task  by  the  form  of  construction 
used,  that  is  the  use  of  separate  swi tches/ ind ica tors  etc.,  and  its 
integrated  nature  with  the  system  electronics  in  terms  of  signal 
drive  These  aspects  also  make  the  MMI  a  d isproportional ly  large 
percentage  of  the  overall  outstation  cost. 

Using  the  experience  gained  on  the  Evaluation  system,  in  conjunc¬ 
tion  with  that  gained  on  Intel  8085  based  systems  already  at  sea,  a 
modified  approach  to  the  concept  of  the  Group  Warning  system  was 
adopted.  Retaining  all  of  the  principle  elements  of  the  original 
system  as  envisaged  by  Vickers  Ltd.,  excepting  nuclear  hardness,  a 
modified  structure  for  the  hardware  was  evolved. 

This  modified  system,  referred  to  as  Dynalec  6000,  has  been  pro- 
totyped  by  HSDE  to  evaluate  the  system  structure.  This  system  differs 
principally  in  the  following  respects. 

(a)  Reduced  nuclear  hardness. 

(b)  The  adoption  of  a  partitioned  structure,  utilising  a  hard¬ 
ware  driven  input  data  scanner  to  acquire  data  from  the  input 
channels  - 

(c)  The  use  of  third  generation  VLSI  computer  chips  and  their 
support  devices. 

(d)  Simplified  software  resulting  from  the  synchronous,  sequen¬ 
tial  operation  of  the  outstation  coupled  with  the  use  of  dedi¬ 
cated  intelligent  devices  to  replace  routine  software  activities. 

Fig . 5  shows  how  the  outstation  breaks  down  into  three  fundamental 
parts. 

The  first  part  is  the  array  of  input/output  modules  which  form 
the  plant  interface.  These  modules  provide  all  of  the  signal  con¬ 
ditioning  required  for  all  of  the  commonly  used  types  of  transducers, 
eliminating  the  need  for  external  signal  conditioning. 
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These  input  modules  also  give  a  measure  of  protection  for  the 
system  electronics  against  damaging  transients  and  careless 
maintainers.  The  system  structure  has  been  organised  such  that  the 
I/O  modules  carry  the  very  minimum  of  the  system  electronics, 
resulting  in  low  cost,  simple  layout  cards,  providing  the  ability  to 
cater  for  new  unforseen  input/output  requirements  with  very  low  appli¬ 
cation  charges.  The  circuit  designs  for  the  plant  interfaces  have 
been  closely  modelled  on  those  developed  on  the  earlier  evaluation 
system. 

The  second  part  is  the  scan  controller  which  controls  the  operat¬ 
ion  of  the  input/output  modules.  This  module  contains  the  high  cost 
parts  of  the  data  acquisition  electronics  such  as  the  Analogue  to 
Digital  Converter.  The  system  used  by  this  module  to  drive  the 
interfacing  modules  is  based  upon  a  simple  counter  and  is  configured 
specifically  for  easy  fault  finding  using  test  equipment  limited  to 
the  multi-meter  level.  The  output  of  this  module  is  a  15  bit  data 
word  per  channel  held  in  a  buffer  store. 

The  final  part  of  the  outstation  is  the  computer  which,  as  a 
result  of  the  use  of  3rd  generation  VLSI  devices,  can  be  organised  as 
a  double  module.  This  double  module  contains  all  of  the  electronics 
which  may  prove  difficult  to  fault  find  in  service.  Hence,  in  the 
event  of  a  failure,  if  the  diagnostic  software  is  unable  to  identify 
the  fault,  then  the  technique  of  repair  by  replacement  is  invoked. 

This  double  module  performs  the  functions  of  scaling,  comparison  with 
warning  limits,  warning  flag  generation,  channel  inhibit  and  data 
transmission  via  the  serial  data  link  to  the  central  station. 

The  strictly  sequential  operation,  together  with  the  intelligent 
devices  used  to  unload  the  processor  of  the  communication  burden, 
reduce  the  software  requirement  for  this  system  to  approximately  half 
of  that  required  for  the  previous  bipolar  based  system.  The  programm¬ 
ing  language  used  is  CORAL  66,  the  language  preferred  by  the  Ministry 
of  Defence. 

One  of  the  key  features  of  the  system  is  that  the  "intelligence” 
is  partitioned  off  into  a  single  module,  this  allows  considerable 
scope  to  adopt  alternative  processors  or  use  different  programming 
languages  to  meet  individual  customer  requirements. 

One  feature  of  the  system  which  is  of  major  importance  to  a 
system  user  is  that  the  outstation  is  configured  to  the  customers 
signal  requirements,  on  site,  by  ship's  staff  using  the  Man  Machine 
Interface,  so  eliminating  expensive  application  changes. 

The  MMI  in  this  system  is  connected  to  the  outstation  via  uhe 
industry  standard  V24/RS232  serial  data  link.  This  provides  the  maxi¬ 
mum  flexibility  to  match  the  customer  requirements  with  the  ability  to 
use  almost  any  form  of  MMI  ranging  from  simple  commercial  hand  held 
Micro  terminals  through  conventional  VDU/Keyboard  terminals  to  spe¬ 
cially  designed  intelligent  panels  tailored  exactly  to  the  customer 
requirements . 

With  MMI  design  being  such  an  emotive  topic  this  "bolt  on  extra" 
nature  which  permits  even  radical  changes  to  be  imposed  on  the  design 
with  minimal  impact  on  the  system,  is  a  valuable  feature  in  reducing 
system  development  costs  and  reduces  the  risk  of  ending  up  with  an 
unwanted  compromise.  B  2-13 


In  order  to  cope  efficiently  with  the  high  volumes  of  data,  the 
central  station  utilises  two  double  modules.  One  of  these  is  dedi¬ 
cated  to  the  communications  task  of  receiving  data  from  up  to  twenty 
outstations  and  supplying  all  of  this  data  to  a  separate  surveillance 
processor. 

The  second  module  provides  all  of  the  functional  facilities  such 
as  the  Group  Warning  Window  drive,  the  warning  VDU  display,  the  Auto 
Inhibit  facility,  drive  for  logger/printer  etc. 

The  industry  standard  common  bus  structure  used  by  these  two  pro¬ 
cessor  modules  can  be  extended  giving  the  ability  to  add  on  additional 
processing  power  to  carry  out  Health  and  Trend  monitoring  tasks. 

The  use  of  third  generation  VLSI  microprocessors  and  support 
devices  has  permitted  a  very  much  more  efficient  packaging  arrangement 
to  be  adopted,  such  that  now  all  of  the  electronics  including  the 
power  supply  and  RFl  filtering  can  be  contained  within  a  single  19  inch 
card  frame.  The  component  count  is  only  45%  of  that  required  with  the 
bipolar  system  and  the  discrete  wiring  is  reduced  to  less  than  1%  of 
the  former  level.  The  impact  on  both  manufacturing  costs  and  system 
reliability  are  self  evident- 

This  compact  nature  now  permits  the  overall  electronics  package  of 
the  outstation  to  be  a  Major  Line  Replaceable  Unit.  This  enables  all 
of  the  ships  cabling  to  be  installed  to  a  special  "junction  box”,  and 
checked  out  with  all  transducers,  prior  to  the  electronics  package  being 
plugged  into  the  "junction  box”.  The  electronics  modules  form  Minor 
Line  Replaceable  Units. 

Health,  Trend  and  Performance  Analysis 

The  by  product  of  having  all  the  plant  data  available  at  the 
central  station  is  the  ideal  opportunity  of  introducing  computer  sur¬ 
veillance  techniques.  This  may  be  carried  out  by  either  installing  a 
separate  processor  connected  by  a  serial  data  link,  or  by  extending 
the  processing  capability  at  the  central  station. 

The  task  of  the  surveillance  processor  is  to  present  the  extensive 
amount  of  information  available  in  a  variety  of  forms  depending  upon 
the  purpose  of  tne  user.  These  techniques  have  been  more  widely  used 
in  industrial  monitoring  systems  than  in  warships  at  the  present  time, 
and  the  examples  below  are  taken  from  software  developed  by  other  pro¬ 
duct  areas  within  the  authors  company. 

(a)  Storage  of  data  at  sampling  intervals  selected  from  an  inter¬ 
active  VDU  console,  which  may  be  milliseconds  for  perfor¬ 
mance  analysis  or  24  hours  for  logging  or  historical  records. 

(b)  Averaging  and  correction  of  data.  For  a  trend  curve  (Fig  8) 
readings  are  only  taken  after  steady  running  has  been  establ¬ 
ished,  and  averaged  to  reduce  scatter.  They  are  then  correc¬ 
ted  for  ambient  and  running  conditions  and  a  corrected  value 
logged.  These  values  can  then  be  displayed  on  a  time  axis 
and  extrapolated  if  required. 
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(c)  Performance  using  non-d imensional  parameters  can  be  calculated 
and  displayed  both  to  help  diagnosis  and  detect  deterioration 
before  damage  results.  The  example  of  Fig  9  shows  a  sudden 
drop  in  efficiency  which  might  easily  be  missed  from  examin¬ 
ation  of  individual  parameters. 

(d)  Presentation  of  data  on  the  interactive  visual  display  can 

be  in  graphic  form  or  using  mimic  diagrams  with  current  para¬ 
meter  values  superimposed. 

(e)  The  routine  paperwork,  of  logging  and  reporting  can  be  reduced 
using  keyboard  entry  to  pre-f ormatted  checklists,  making  more 
time  available  for  using  the  health  monitor  techniques  above. 
This  increases  the  interest  and  technical  content  of  the 
watchkeeper 1 s  role,  which  can  otherwise  be  reduced  to  monoto¬ 
nous  paperwork  by  automated  control. 

Summary 

The  evaluation  system  has  clearly  demonstrated  the  penalties 
incurred  in  implementing  sophisticated  systems  whilst  limiting  the 
choice  of  semiconductor  devices  to  the  nuclear  hard  varieties. 

However,  this  system  has  proved  the  operational  philosophy  as  well  as 
providing  invaluable  experience  on  plant  interfacing  and  software 
structure . 

By  taking  advantage  of  the  much  higher  "intelligence"  level  avail¬ 
able  in  third  generation  V.L.S.I.  processors,  an  alternative  to  the 
evaluation  system  is  being  developed  by  HSDE.  The  range  of  support 
devices  available  for  third  generation  processors  enable  the  overall 
system  performance  to  be  improved  by  several  orders  of  magnitude 
whilst  halving  the  component  count.  This  saving  is  further  reflected 
by  a  reduction  in  power  supply  requirements  resulting  in  a  more 
compact  piece  of  hardware  with  improved  mainta inabil ity . 
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MACHINERY  CONTROL  AND  SURVEILLANCE  -  SOFTWARE  DESIGNED 
FOR  RELIABILITY  AND  MAINTAINABILITY 

by  I.  \V.  Pirie,  M inistry  of  Defence,  DO  Ships,  Bath 
and  R.  Foulkes,  Y-ARD  Limited,  Glasgow 

ABSTRACT 

The  paper  is  concerned  with  the  design  of  software  for  multi- computer 
systems  to  minimise  the  full  life  costs  of  those  systems,  with  particular 
reference  to  the  design  of  software  for  twt>  shipborne  equipments: 

(a)  A  machinery  control  system  (Demonstrator)  currently  under 
development  for  MOD  by  Hawker  Siddeley  Dynamics  Engineering  Ltd 
(HSDE) 

(b)  A  secondary  surveillance  system  under  development  for  MOD  by 
Y-ARD  Limited  of  Glasgow',  Scotland. 

Particular  attention  is  paid  to  the  way  the  software  is  partitioned  and 
organised  for  multi- purpose  us>e.  The  mecharism  of  test  and  verification 
for  common  utilities  is  discussed  and  the  mechanism  for  packaging  the 
releases  of  software  is  presented.  The  ability  to  move  the  software  between 
computers  of  entirely  different  architectures  is  stressed  and  the  methods  used 
in  the  production  of  one  of  the  utility  packages  are  described. 

With  the  benefit  of  hindsight,  a  review’  of  the  effect  of  the  project  plan 
and  of  sorre  of  the  lessons  learnt  during  development  is  presented. 


INTRODUCTION 

As  part  of  the  ongoing  work  programme  (Reference  1)  to  secure  the 
advances  in  new  technology  for  future  generations  of  control  and  surveillance 
systems  substantial  progress  has  been  made  in  overcoming  many  of  the 
problems  likely  to  result  from  the  use  of  computer  software  in  those  systems. 
A  first  hand  understanding  of  the  difficulties  likely  to  be  experienced  in  using 
distributed  computers  to  perform  a  propulsion  machinery  control  task  was 
obtained  using  a  Propulsion  Control  System  Test  Rig  (Reference  2).  This 
work  showed  that,  in  order  to  meet  the  requirements  of  rcl  able,  maintainable, 
transportable  and  flexible  software,  certain  design  objectives  had  to  be  met. 
These  were: 

(a)  A  good  software  structure  w  as  required,  whereby  jobs  to  be  carried  out 
w'ithin  a  processor  were  isolated  from  each  other  by  an  executive  which 
imposes  constraints  on  the  privileges  of  the  individual  tasks.  This 
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software  structure  was  to  be  S'  ch  that  the  data  transmission  system  was 
transparent  to  the  remainder  of  the  software  in  each  processor. 

(b)  The  software  design  was  to  be  modular  for  ease  of  documentation,  testing 
and  management.  The  documentation  was  to  allow  for  a  life  of  25  years  and 
remain  as  independent  of  the  hardware  as  possible. 

First  the  software  structure  will  be  described,  then  the  main  body  of  the 
paper  will  be  devoted  to  describing  the  implements t  on  of  that  structure  to 
achieve  the  other  design  objectives  and  thereby  meet  the  software  requirements. 

SOFTWARE  STRUCTURE 

A  diagram  of  the  software  structure  is  shown  in  Figure  1.  The  main 
software  tasks  are  shown,  together  with  the  hardware  interfacing  to  the  outside 
world.  The  executive  which  allocates  the  resources  between  the  tasks  is  the 
MASCOT  kernel  which  exists  in  each  processor.  Each  of  the  software  tasks 
shown  is  independent  in  the  sense  that  it  has  a  specific  job  to  do  and  the  only 
constraint  on  how  the  job  is  done  is  the  way  in  which  each  function  interfaces 
with  another.  Thus,  a  control  sub- system  may  be  designed  or  altered  without 
having  any  detailed  knowledge  of,  say,  the  Data  Management  Task  but  only  a 
knowledge  of  how  to  interface  with  that  ta^K. 

To  explain  the  overall  structure,  consider  a  transducer  signal  from  the 
plant  which  is  required  for  a  control  function  and  which  is  to  be  displayed 
remotely  in  the  Ship’s  Control  Centre.  The  signal  is  first  filtered ,  amplified, 
multiplexed  and  digitised  by  the  hardware.  It  then  passes  to: 

INTERFACING  -  wrhere  it  is  scaled  and  compared 

against  limits.  It  then  passes  to: 

DATA  MANAGEMENT  -  where  a  system  wide  address  is 

added  so  that  information  is  clearly 
identified  for  use  anywhere  in  the 
system.  This  task  keeps  a  store  of 
data  and  passes  it  out  to  consumers 
as  required.  The  prime  consumers 
are  the  Controls’  (or  applications') 
tasks  located  in  each  processor.  To 
communicate  between  processors 
the  Data  Management  in  one 
processor  initiates  a  data  link  to 
another  precessor  on  start-up.  The 
Data  Management  task  in  the  other 
processor  constructs  messages 
containing  the  required  data  which  are 
then  automatically  exported  each  time 
the  parameters  are  updated.  Data 
Management  uses: 
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MESSAGE  KOUTEING  -  to  steer  messages  to  the  correct 

processor  via; 

COMMUNICATIONS  HANDLING  -  which  organises  the  transmission. 

This  task  contains  the 
implementation  dependent  aspects  of 
the  communications*  system, 
sometimes  called  the  high  level 
protocol.  Messages  pass  from  this 
software  task  to  the  hardware 
implementation  of  the  data  link  used. 

ERROR  REPORTING  -  is  a  supervisory  task  which  receives 

notice  of  errors  from  all  activities 
in  the  software.  These  errors  are 
reported  to  the  maintainer. 

This  structure  has  been  implemented  in  a  development  contract  placed 
by  MOD  on  HSDE  for  the  Demonstrator  control  system  which  uses  distributed 
processors  to  perform  propulsion  control  and  surveillance  tasks  according  to 
their  place  in  the  controls'  hierarchy  Figure  2.  The  functional  design 
underlying  the  control  system  will  be  found  in  Reference  3. 

Associated  with  the  controls'  system  is  a  surveillance  and  data  collection 
system  called  the  Propulsion  and  Auxiliary  Secondary  Surveillance  (PASS) 
system  (Figure  2).  This  system  development  is  described  in  Reference  4, 

The  software  structure  for  the  PASS  system  is  similar  to  that  used  in  the 
Demonstrator  control  system  using  the  same  common  tasks  of  Data 
Management  and  Message  Routeing,  but  with  different  applications  software. 

Software  Lifetime  and  its  Problems 

Before  starting  work  on  a  system  containing  embedded  computers  it  is 
worthwhile  looking  ahead  to  the  maintenance  and  other  operational  problems 
likely  to  be  encountered  during  its  lifetime,  since  that  is  where  a  large 
proportion  of  its  overall  cost  is  likely  to  reside.  In  such  a  case  as  that  which 
we  are  considering,  of  fitting  computer  embedded  systems  to  ship's  machinery, 
consider  the  following  statements: 

"It  has  been  20  years  since  the  first  ship  was  fitted  with  the  NOPRANG 
computerised  machinery  control  system.  Since  men  it  has  been  fitted  to 
23  ships  in  the  Fleet. Currently,  only  2  (the  latest  built)  of  the  ships  are 
running  identical  software.  Using  the  2  latest  ships  as  a  baseline,  a  recent 
analysis  of  why  the  remaining  21  are  running  different  software  sets 
revealed: 

10  are  different  because  the  equipment  they  are  controlling  is  different. 

7  are  different  because  they  are  using  a  variety  of  old  computer  hardware 
still  not  replaced  from  the  previous  programme  of  refits  of  controllers 
started  15  years  ago. 

13  are  different  because  they  are  at  five  different  operational 
modification  states  and  are  awaiting  upgrades. 
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The  discrepancy  in  totals  is  caused  by  some  ships  having  more  than  one 
reason  for  differences.  We  are  looking  forward  to  a  period  of  stability 
after  the  current  refit  programme  has  replaced  all  the  computer  hardware 
with  the  MIGHTYMOUSE  chip  '. 

It  may  be  that  there  are  no  circumstances  in  which  the  reader,  as,  say,  the 
person  responsible  for  the  control  system,  would  have  allowed  it  to  get  into  such 
a  state.  Unfortunately,  many  engineers  have  discovered  that  it  is  impractical 
to  keep  the  design  state  of  computer  embedded  systems,  such  as  ships’  control, 
synchronised  with  each  other,  often  owing  to  circumstances  beyond  their 
control.  It  is,  therefore,  worthwhile  acknowledging  the  above  scene  as  a 
remote  possibility,  ensuring  that  it  could  be  coped  with,  and  then  trying  to  avoid 
getting  into  it'  The  big  problem  is  what  to  do  during  development  to  enable 
the  maintainers  of  the  system  to  cope.  This  section  of  the  paper  describes 
some  of  the  areas  considered  during  development  of  the  new  generation  of  UK 
surface  ship  machinery  control  and  surveillance  system,  what  was  done  about 
them  and,  with  the  benefit  of  hindsight,  what  has  been  learnt. 

Configuration  Control 

Often  left  until  last,  the  area  of  software  and  hardware  configuration 
control  should  be  tackled  early  in  *ne  development  phase.  By  'configuration 
control'  we  mean  the  ability  to  guarantee  an  accurate  knowledge  of  exactly 
what  is  fitted  to  operational  or  experimental  systems  to  allow  the  diagnosis  of 
faults  and  achieve  control  over  the  development  of  (or  other  changes  to)  the 
system. 

In  which  ways  do  the  requirements  of  configuration  control  affect  the 
design?  The  following  provides  some  indications: 

To  control  the  hardware  and/or  software  as  one  massive  block  with  no 
internal  structure  is  very  difficult.  Fault  reports  from  one  issue  of  the 
system  (such  as  a  ship)  are  difficult,  if  not  impossible,  to  relate  to 
other  issues.  Slight  differences  between  hardware  fits  are  very  difficult 
to  manage.  Configuration  control  demands  a  software  and  hardware  hier¬ 
archical  structure  of  assemblies,  sub- assemblies  and  components  in  order 
to  manage  both  software  and  hardware.  It  is  almost  impossible  to  generate 
retroactively  such  a  hierarchical  structure  in  an  implementation  designed 
and  built  without  it. 

Configuration  control  makes  demands  on  the  way  in  which  changes  are 
implemented  to  both  hardware  and  software  and  the  way  in  which  issues  to 
the  field  are  synchronised  with  the  changes.  The  designer  has  to  try  to 
reduce  the  scope  of  changes  to  both  hardware  and  software  caused  by 
outside  influences.  It  may  appear  obvious  that  changes  relating  to  the 
operational  parameters  of  a  gas  turbine  should  be  located  in  one  small  area 
of  software  and  hardware  and  not  scattered  all  over  the  implementation;  not 
so  obvious,  perhaps,  is  the  necessity  to  do  the  same  for  communication 
hardware  changes,  the  software  for  which  occurs  in  every  computrr. 
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The  following  gives  some  idea  of  the  impact  of  configuration  control  on  the 
implementation,  that  is,  the  work  necessary  to  produce  one  set  of  the  hardware 
and  software  and  get  it  working  in  a  ship: 

It  is  quite  difficult  to  change  implementation  engineers  from  working  in 
an  environment  in  which  there  are  few  checks  on  the  ability  to  change 
permanently  a  module  of  software  (or,  for  that  matter,  a  printed  circuit 
board)  to  the  environment  demanded  by  configuration  control.  It  is 
important,  therefore,  to  start  out  with  a  moderately  disciplined  approach 
and  to  relax  procedures  where  necessary,  rather  than  to  start  out  in  an 
undisciplined  way. 

Configuration  control  demands  that  the  system  for  a  particular  ship  can  be 
constructed  from  the  documentation  alone,  any  knowledge  inbuilt  into  the 
heads  of  the  developers  being  a  dangerous  thing.  In  order  to  validate  such 
a  requirement,  the  original  system  must  be  constructed  in  a  way  that 
allows  someone  not  associated  with  the  implementation  team  to  generate 
a  system  for  a  ship.  Before  development  is  complete  the  configuration 
control  department  must  issue  a  ship  fit  system. 

How  does  the  way  in  which  the  software  has  been  designed  for  the 
described  systems  assist  in  the  area  of  configuration  control?  Every  item  of 
software  maintained  in  magnetic  form,  whether  computer  programs  or  build 
instructions,  is  part  of  a  'module*  which  corresponds  with  a  circuit  diagram 
in  hardware  terms.  The  module  contains  some  administrative  information 
such  as  name,  modification  states,  title,  description,  Q-A  approvers,  etc., 
together  with  the  appropriate  code.  At  the  time  of  writing  only  the  shared 
code  areas  are  under  full  configuration  control.  The  size  of  each  module  is 
controlled  in  a  similar  manner  to  the  contents  of  a  circuit  diagram,  i.  e.  on 
the  basis  of  a  reasonable  looking  area  of  code,  functionally  separate  from 
other  areas  and  assessed  by  the  quality  control  group  as  being  a  reasonable 
module  size  and  complexity  for  support  purposes. 

The  modules  are  the  components  of  'packages’  which  generally  implement, 
areas  of  functionality  such  as  communications,  data  management,  machinery 
control,  etc.  A  package  is  the  smallest  issuable  entity  and  may  contain 
pointers  to  other  packages  to  completely  define  a  software  issue.  The  user  fault 
reporting  system  is  based  on  packages,  only  being  routed  down  to  module  level 
by  the  subsequent  analysis  of  the  fault. 

Although  the  tight  change  control  demanded  of  the  final  configuration 
control  cannot  conveniently  be  applied  during  development,  the  general 
framework  of  development  within  such  an  environment  has  been  maintained. 
Typically  the  configuration  control  system  retains  all  the  module  sources, 
retaining  old  versions  appropriately,  and  producing  suitable  reports  for  the 
Q-A  inspection  which  is  generally  only  carried  out  via  configuration  control. 
During  development  the  requirement  to  raise  a  change  notification  for  every 
single  code  change  is  relaxed.  We  have  found,  however,  that  subsequently 
adding  an  'authority  to  proceed*  to  a  change  request  system  is  easy  compared 
with  retroactively  adding  a  complete  configuration  control  system.  It  has 
been  found  that,  after  initial  reluctance,  the  programe  designers  and 
implementcrs  accept  the  use  of  configuration  control  as  an  improvement  of 
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facilities  and  not  an  imposition  of  management. 

Testing  and  Re-testing 

The  requirements  of  testing  and  re- testing  are  important  factors  in  the 
design  of  long  life  software.  It  is  necessary  to  build  the  ability  to  test  the 
software  into  the  design.  If,  for  example,  a  large  quantity  of  software  is 
intimately  linked  to  the  hardware  on  which  it  runs,  making  it  impossible 
to  test  the  software  remote  from  tt.e  target  hardware,  it  is  likely  that  a 
considerable  portion  of  the  Fleet  will  be  tied- up  alongside  for  software  testing 
purposes.  Over  the  lifetime  of  the  software,  changes  are  often  made  in  every 
functional  area.  Since,  unhappily,  one  of  the  known  characteristics  of  fixing 
software  problems  is  the  generation  of  new  ones,  it  is  important  to  at  least  be 
able  to  re-execute  the  tests  which  were  originally  used  to  declare  the  software 
'working',  and  preferably  to  be  able  to  extend  the  tests  or  test  cases  to  include 
the  fault  which  previously  escaped. 

In  a  similar  manner  to  electronic  hardware,  the  c.uestion  of  how  automatic 
the  testing  process  should  be,  arises.  A  fully  automatic  test  system  for  which 
a  machine  displays  'PASS'  or  ’FAIL'  is  obviously  preferred,  but  is  a  higher 
capital  outlay.  Furthermore,  some  areas  are  not  as  amenable  to  this  form  of 
testing  as  others.  However,  the  sensitive  areas  of  both  the  systems  described 
are  covered  by  pass/fail  tests  which  are  configurable  in  several  different 
ways.  The  main  areas  covered  are: 

Data  accessing  routines 

Communications 

Data  management 

MASCOT  executive 

All  the  test  software,  including  any  test  case  files,  are  held  under 
configuration  control,  along  with  the  software  they  are  testing,  and  are 
maintained  to  the  same  strict  standards  of  quality.  The  tests  have  been 
designed  so  that  they  can  be  executed  by  other  than  the  original  software 
designers  and  implementors.  Generally  the  test  programs  provide  an 
environment  which  looks  identical  to  the  real  world  from  the  point  of  view  of 
the  program  under  test.  In  some  cases,  particularly  when  time  criticality 
is  of  great  import,  this  is  difficult  to  do,  and  in  some  cases  makes  certain 
demands  on  the  final  hardware  such  as  loop- back  connections  in 
communication  systems. 

Documentation  and  Quality  Control 

The  often  stated  demand  that  long  lifetime  software  should  be  'well 
documented'  has  the  difficulty  that  the  words  'well  documented1  are  not  well 
understood.  The  requirement  is  to  allow  for  many  changes  of  staff  members 
during  the  project  lifetime.  In  a  similar  manner  to  modularity,  clear 
documentation  is  almost  impossible  to  fit  retroactively  to  developed  software. 
Not  only  is  it  difficult  to  do  but  it  is  also  psychologically  bad,  in  the  sense  that 
it  is  usually  seen  as  a  chore  to  be  completed  after  all  the  interesting 
programming  work  has  been  done.  Often  the  engineers  producing  the  software 
escape  to  other  jobs  before  completing  the  documentation. 
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In  what  ways  do  the  systems  described  meet  the  documentation 
requirements  of  long  lifetime  software?  An  attempt  was  made  to  document  all 
the  software  from  the  outset  to  a  standard  defined  by  JSP  188  (Reference  5) 
which  requires  a  hierarchical  breakdown  based  on  functionally  identified  areas 
of  software.  The  documentation  was  made  a  part  of  the  quality  and  progress 
inspection  procedures  during  the  development,  heing  used  for  areas  such  as 
design  walkthroughs  and  the  contract  progress  approval  procedures. 

All,  of  course,  was  not  sweetness  and  light.  Most  of  the  problems  were 
caused  by  tight  tiir  escales  squeezing  out  action  required  by  quality  checks 
on  the  documentation  during  the  later  stages  of  the  project.  The  documentation 
strayed  from  the  ideal,  but  never  approached  the  situation  of  being 
irrecoverable. 

Multi-Purpose  Use 

Some  areas  of  software  are  well  suited  for  sharing  amongst  similar 
projects.  There  are  considerable  benefits  if  sharing  can  be  achieved  viz: 

More  reliable  software  (checked  out  by  more  users) 

Lower  support  costs 

Lower  development  costs 

Cross-product  fertilisation  of  techniques  and  ideas 

Early  in  the  development  cycle  some  areas  which  were  suitable  for 
sharing  between  similar  projects  were  identified  viz: 

Data  accessing  routines 

Data  management 

Some  aspects  of  communication 

MASCOT  executive 

even  though  they  had  to  run  on  totally  different  computer  architectures. 

It  was  not  fortuitous  that  these  areas  were  shareable.  Considerable 
effort  was  put  into  functional  identification  during  the  design  stage.  The 
demands  of  shareability  across  different  projects  and  computers  are  quite 
stringent  with  regard  to  the  methods  of  packaging  and  documenting.  With 
deliberate  intent  it  is  possible  to  identify  such  areas  and  the  projects 
described  demonstrate  this  by  sharing  several  areas  between  them  and  with 
other  projects. 

A  word  of  caution  here:  Sharing  has  to  be  judisciously  done,  since  there 
is  often  a  trade-off  between  commonality  and  efficiency.  In  general,  the 
closer  the  programming  is  to  the  application,  the  more  difficult  it  is  to  share 
with  other  applications.  If  one  project  demands  some  modification  to  a 
package  which  is  not  acceptable  to  a  sharing  application  it  is  necessary  to 
support  both  applications  separately.  Packages  which  are  'almost*  the  same 
are  very  difficult  to  control  as  a  single  entity. 
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Software  Mobility 

One  of  the  demands  of  both  long  lifetime  software  and  sharing  of  programs 
between  projects  is  the  ability  to  run  the  programs  on  more  than  one 
computer.  There  is  significantly  more  to  the  problem  than  choosing  a  high 
level  language  and  programming  everything  in  it.  The  decisions  begin  at  the 
design  level  in  choosing  the  levels  of  abstraction  to  ensure  that  the 
peculiarities  of  one  computer  are  not  built  into  the  software  at  too  high  a 
level.  Inevitably  there  are  differences  between  languages,  executives  and 
interfaces,  but  with  careful  partitioning  of  the  software  it  is  possible 
to  minimise  the  effort  needed  to  move  the  software.  In  the  projects 
described  the  techniques  used  to  assist  in  ensuring  the  software  is  mobile  were: 

.  Use  of  MASCOT  (Reference  6)  as  the  executive  interface 

Programming  in  Official  Definition  (Reference  7)  CORAL  66  and 
adjustment  with  a  pre-pass  program  to  particularise  for  a  computer 

Development  on  several  different  computers  (PDP  11,  INTEL  8080, 
Ferranti  F100L)  and  movement  several  times  during  development 

.  Use  of  Test  harnesses  to  allow  re- testing  on  different  computers. 

There  are  some  problems  to  which  we  currently  have  no  solution  and  with 
which  we  have  to  live;  amongst  these  are: 

.  Differing  representation  of  data  items,  such  as  floating  point,  causes  some 
problems,  particularly  if  the  number  of  words  is  different 

,  Differing  instructions  necessary  to  construct  the  software,  particularly 
where  instructions  down  to  placing  the  code  in  read-only  memory  are 
required 

Differing  usage  of  resources,  such  as  stack  allocations,  invalidating  the 
test  cases  designed  to  highlight  resource  problems. 

Example  of  multi  computer,  multi-use  package 

The  following  is  an  example  of  a  package  which  is  currently  used  in  three 
systems  which  was  designed  both  for  multi- computer  use  and  to  allow 
transportability  between  computer  architectures. 

The  particular  package  described  is  DATA  MANAGEMENT,  a  package 
devised  by  Y-ARD  under  contract  to  MOD  for  an  area  of  software  which 
was  unsuccessful  during  a  previous  research  phase,  produced  and  tested 
by  HSDE  and  transferred  under  configuration  control  to  be  used  on  PDPll 
computers  for  PASS  and  on  F100L  for  the  Demonstrator.  It  would  be  an 
indictment  of  the  documentation  scheme  is  this  paper  had  to  create  a  special 
description  of  data  management  or  its  test  system;  modules  from  the  package 
will  therefore  be  used. 
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MODULE  NAME 
DMT ASK 

DESCRIPTION  CLASSIFICATION 
UNCLASSIFIED 
CODE  CLASSIFICATION 
UNCLASSIFIED 
TITLE 

DATA  MANAGEMENT  TASK  DESCRIPTION 
TYPE  NAME 

DESCRIPTIVE  DMT ASK 

DESCRIPTION 

This  nodule  describes  Date  Management  at  the  task  level.  It  Is  a 
generalised  description  chat  aay  be  adapted  as  a  basis  for  particular 
appl lcetions. 

1.  AIMS  OF  DATA  MANAGEMENT. 

Data  Management  is  a  aetnod  of  transacting  date  thioughout  a  distributed 
computer  system.  The  types  of  data  Item  (parameter)  handled  have  the  following 
characteristics. 

a  A  unique  identifier  can  be  given  to  the  parameter.  DM  requires  a 
Parameter  number. 

b  The  parameter  has  a  fixed  length.  DM  allows  ar.y  number  of  parameter  lengths. 

But  requires  that  the  first  word  of  a 
parameter  is  the  status  word. 

c  The  parameter  has  only  one  source.  DM  requires  this. 


Message  data  that  may  have  varying  length  and  meaning  and  aay  have  multiple 
sources  and  that  ceases  to  be  meaningful  once  operated  upon  is  specifically 
'■xcluded.  The  characteristics  of  data  management  are: 

(a) the  originator  need  not  have  knowledge  of  the  users  of  a  3lven 
parameter . 

(b) the  users  need  not  have  knowledge  of  the  originator  of  a  given 
parameter . 

(c) the  originator  and  users  may  be  in  different  computers. 

(d) uae  of  facilities  of  data  management  does  not  require  a  detailed 
knowledge  of  the  format  of  the  data  management  data  base. 

(e) che  method  of  communication  of  parameters  throughout  the  system 
is  Mddlh  from  the  user. 

Dati  Management  undertakes  the  task  of  communicating  parameter  dat«  throughout 
a  system  such  that  up  to  date  values  of  parameters  are  available  to  all  users  that 
require  them  as  soon  as  possible. 

DM  requires  that  user  activities  declare  their  interest  in  particular 
parameters.  If  the  _ser  activity  requires  tne  parameter  for  read  then  DM  sets 
ud  the  linkages  to  the  parameter  source,  if  the  source  is  in  a  remote 
computer  then  the  linkages  are  set  up  to  have  the  remote  computer  send  the  data  value 
to  the  local  computer  each  time  the  value  is  changed.  If  the  user  activity 

generates  a  parameter  then  DM  Informs  the  system  so  that  local  and  external  links  can  be  made 
with  activities  that  require  the  parameter  value. 

2.  DESCRIPTION  OF  THE  TASK 

The  CM  Task  consists  or  a  number  of  subsystems  of  which  there  may  be 
one  or  more  in  each  computer  that  requires  DM  facilities.  The  actual  number 
is  dependent  upon  the  application.  The  structure  of  tne  subsystems  is 
described  in  module  DAMASS. 

The  subsystem  communicates  with 

a  Other  DM  subsystems  -  External  links 

b  USER  TASKS  via  a  POOL  -  Local  links. 

The  form  of  the  external  links  is  system  dependent. 

The  POOL  is  defined  oy  DBDES .  Access  to  the  local 

PARAMETER  POOL  both  by  DAMASS  and  USERTASKS  is  only  made  by  via  operators.  These 
operators  are  describee  in  module  DMOP. 

2.  INITIALISATION  OF  SUBSYSTEM  AND  DATA  AREAS 

It  is  necessary  to  initialise  the  subsystem  and  the  data  areas.  The 
method  of  doing  this  la  described  in  module  DMISIT. 

ENDOFCESCRIPTICN 
ERRORS  REPORTED 


Figure  3  -  Introduction  to  the  Concept  of  Data  Management 
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MODULE  NAME 

0K2SUBSY5TEKDES 
DESCRIPTION  CLASSIFICATION 
UNCLASSIFIED 
CODE  CLASSIFICATION 
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TITLE 

DATA  MANAGEMENT  SU6SYSTEM  DESCRIPTION 
TTPE  NAME 

DESCRIPTIVE  DKSUBSTEJOES 

DESCRIPTION 
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FIGURE  1  -  DATA  MANAGEMENT  SUBSYSTEM 


Figure  4  -  Sheet  1  Parallel  Co-operating  Processes  in  Data  Management 
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DESCRIPTION  OF  SUBSYSTEM 
PARAMETER  POOL 

This  pool  contains  tables  of  information  about  which  locally  written 
parameters  are  required  by  other  DM  subsystems  and  which  DM  subsystems 
require  them.  It  contains  information  on  parameters  whose  source  is 
non-local  but  are  required  locally.  The  complex  data  structure  also  contains 
pointers  into  a  list  of  the  read,  write  and  edge-trigger  tables  set  up 
by  the  user  tasks. 

USER  TASK 

This  represents  the  user  tasks  which  access  the  DM  PARAMETER  POOL  using 
the  access  procedures  defined  in  module  DHOP. 

CHANNELS 

The  channels  REP VCHAN , SEPVCHAN , RIPMCHAN  and  SIPMCHAN  are  used  to  send/receive 
messages  for  the  corresponding  activities  (see  below).  The  channel  protocol 
is  defined  in  module  SIKPLESTRUCTURE. 


repv 

This  activity  receives  messages  containing  parameter  update  values  from 
remote  DM  subsystems.  The  values  are  written  into  PARAMETER  POOL  where 
they  can  be  read  by  USER  TASK.  If  any  of  the  parameters  are  edge- trigger 
accessed  then  the  appropriate  STIM  is  made  on  the  USER  TASK.  The  activity 
root  procedurre  is  defined  in  module  REPV. 


RIPM 

This  activity  receives  messages  from  remote  DM  subsystems.  These  messages 
are,  In  general,  used  to  set  the  links  between  the  DM  subsystems  and 
lavolve  declarations  of  parameters  availability,  requests  for  access  to 
parameters  not  available  locally  to  the  requesting  subsystem,  access 
cancellations  etc.  The  message  protocol  and  message  content  is  defined  In 
defined  in  module  IPMDES.  The  activity  root  procedure  is  defined  in  module 
RIPM. 


SIPM 

This  activity  is  used  to  send  messages  to  remote  DM  subsystems.  The 
messages  will  be  received  by  a  RIPM  activity  In  the  remote  processor  see 
RIPM  above.  The  activity  root  procedure  is  defined  in  module  SIPM. 


SEPV 

This  activity  sends  messages  to  remote  DM  subsystems  containing  parameter 
update  values  of  locally  written  parameters.  It  is  activated  via  the  edge- 
trigger  tables  in  PARAMETER  POOL  when  externally  requested  parameters  are 
updated.  The  activity  root  procedure  is  defined  in  module  SEPV. 


Figure  4  -  Sheet  2  Parallel  Co-operating  Processes  in  Data  Management 


B  3-13 


MODULE  NAME 
CM27EST 

DESCRIPTION  CLASSIFICATION 

unclassified 

CODE  CLASSIFICATION 

unclassified 

TITLE 

TEST  SYSTEM  FOP  DATA  MANAGEMENT 
TYPE  NAME 

DESCRIPTIVE  DM2 TEST 

DESCRIPTION 

This  module  describes  a  teat  system  for  Data  Management  Task- 

The  D.M.  taste  operates  aa  a  set  of  functionlly  identical  subsystems, 
possibly  in  separate  processors  and  the  teat  system  taxes  the  following 
into  consideration. 

al  To  test  the  interaction  of  D.M.  subsystems  fully  at  least  two  D.M. 
subsystems  must  be  Included.  They  may  Or  may  not  be  in  the  same 
processor . 

5)  Even  when  in  separate  processors  the  D.M.  subsystems,  rroo  their  point 
of  view,  will  appear  to  coaaunieate  with  each  other  directly  through 
MASCOT  channels.  This  is  achieved  by  using  a  suitable  inter-processor 
communications  facility. 

c)  Ideally  the  test  should  be  independent  of  the  number  of  D.H.  subsystems 
(configurable  during  initialisation  at  all  levels)  and  whether  they  are 
in  separate  processors;  However  due  to  size  restrictions  it  wiLl  have 
a  fixed  configuration  of  two  D.M.  subsystems. 

For  the  test  a  D.M,  subsystem  will  be  attached  to  one  of  two  harness  types 

a)  Master  Harness.  There  will  be  one  Master  Harness  in  a  test  system. 

(See  MATTER). 

b)  Slave  Harness.  There  will  be  a  Slave  Harness  for  the  secondary  D.M. 
subsystem.  ;see  SLAVE). 

The  test  functions  to  be  carried  out  are  described  in  TEST  FUNCTIONS  and 
the  following  test  strategy  is  adopted, 
a'  each  D.*'.  subsystem,  SLAVE  or  MASTER  is  referenced 

by  a  D.M.  Subsystem  Identification  number  for  the  test.  (See  INITDEF). 

b)  associated  with  the  slave  D.M.  is  a  set  of  parameter  numbers  X00-X99 
where  X  is  the  D.M.  lubsystem  Identification  number  of  the  slave. 

c)  parameter  XGO  is  taKen  to  be  the  synchronisation  count  and  its  value  is 

adjusted  by  the  master  tr  the  stages  of  the  test  to  the  slave 

subsystem  and  the  parameters  to  wmch  it  should  have  write  access. 

d)  the  slave  harness  Is  as  simple  as  poss.ble  and  takes  eoge-trlgger 
access  on  parameters  X00-XA9  and  write  access  fcr  the  parameters 
X50-X99.  When  any  of  the  ET  parameters  are  written  to  the  slave  writes 
the  new  value  of  XY2  to  XTZ+50. 

e)  the  master  is  in  coepiete  control  and  executes  the  test  reads,  writes 
and  ET  access  on  the  parameters,  both  local  and  external.  The  master 
will  have  full  Knowledge  of  the  external  parameter  states  and 
values  because  of  c)  and  d)  above. 

The  steps  in  the  testing  of  the  Data  Management  Tasx  are  as  follows 
a)  test  the  master  and  the  single  slave,  within  a  single  processor. 

8)  lest  the  master  and  tne  slave  in  separate  processors. 

C>  test  the  master  and  several  Slaves,  all  In  separate  processors.  This 
will  require  modification  to  coding  in  DM27E5T. 


Figure  5  -  Test  Techniques  used  in  Data  Management 
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MODULE  SAME 
DHTESTSYSTEM 

DESCRIPTION  CLASSIFICATION 
UNCLASSIFIED 
CODE  CLASSIFICATION 
UNCLASSIFIED 
TITLE 

MULTI -PROCESSOR  DATA  MANAGEMENT  TEST  STSTEM 
TYPE  NAffi 

DESCRIPTIVE  DHTESTSYSTEM 

DESCRIPTION 

This  module  describes  the  principles  behind  the  design  of  e  multl- 
processor  Data  Management  test  system. 

The  test  system  is  designed  with  the  following  in  mind 

a)  Wherever  possible  the  test  software  should  be  configurable  and  easily 
adapted  to  any  number  of  processors, 
o)  In  the  normal  operation  of  the  test  .11  operator  interaction  should 
be  confined  to  a  single  processor  to  mak.'  the  execution  and  checking 
of  the  test  operation  as  simple  as  possible, 
c)  The  test  is  intended  to  exercise  the  inter-subsystem  protocols  of 
Data  Management  in  a  target  hardware  multi-processor  environment.  It  is 
not  intended  as  a  comprehensive  test  on  the  user  Interface  or  a  line-by¬ 
line  test  of  the  Internal  logic. 

The  following  test  strategy  is  adopted. 

a)  There  is  one  "test  master"  processor  containing  the  "test  master" 
subsystem  and  each  of  the  other  processors  contain  a  "test  slave" 
subsystem.  The  "test  master”  invokes  all  operator  interaction. 

b)  It  doesn't  matter  which  of  the  processors  contains  the  "test  master" 
subsystem  but  the  communications  in  each  processor  should  be  configured 
as  if  for  the  final  system. 

c)  The  "test  master"  subsystem  takes  write  access  on  two  parameters 
1)1-  this  is  a  control  parameter  and  the  slaves  take  special 

action  dependant  on  its  value,  In  this  way  the  master  will 
know  what  should  be  happening  in  each  of  the  slaves  at  any 
given  time. 

100  -  this  is  a  "seed"  parameter  and  other  sets  of  parameters, 

whose  sources  are  in  the  slaves,  have  their  values  updated 
to  match  the  "seed*  parameter. 

d)  The  "test  slave"  subsystems  take  write  access  on  their  own  primary 
parameter  and  keep  it  updated  to  match  parameter  100  i.e.  slave  number 
i  copies  value  of  100  to  101,  slave  number  2  copies  value  of  100  to 
102  etc.  The  slaves  also  read  all  the  primary  slave  parameters  and 
write  the  updates  to  a  new  parameter  i.e.  1QX  -  1YX  where  X  is  slave 
identifier  and  Y  is  the  slaves  own  identifier.  When  there  are  three 
slaves  then  slave  2  operates  with  100-102,101-121,102-122  and 
103-123.  This  means  that  every  teat  subsystem  reads  a  parameter  from 
every  other  subsystem  and  every  subsystem  writes  a  parameter  which 

is  read  by  every  other  subsystem. 

e)  The  "test  master"  takes  read  access  on  parameters  Itl  ...  INN 
where  N  is  the  number  of  slaves.  Each  update  to  100  should  cause 
the  update  to  eventually  be  made  to  all  of  these  parameters. 

f)  The  test  is  made  continuous  by  the  master  using  the  control  word  to 
tell  the  slaves  to  cancel  write  access  on  Its  parameters.  The  master 
then  waits  until  all  Its  read  parameters  have  a  status  showing  that 
the  parameters  have  no  current  source  i.e.  all  cancels  sequences  are 
complete,  it  then  sets  the  control  value  to  tail  the  sLaves  to 
re-request  write-access  to  its  parameters.  ATter  a  sequence  of  value 
updates  a  cancel  word  is  sent  and  the  cycle  is  repeated. 

g)  The  subsystems  are  made  configurable  with  respect  to  parameter  site 
and  the  test  should  be  repeated  for  all  sizes  or  If  memory  space  allows 
then  multiple  copies  of  the  subsystems  should  be  run  concurrently 

for  sore  than  one  parameter  size. 

The  "test  master"  subsystem  is  described  in  module  MPDMMAcTER 
The  "test  slave"  subsystem  is  described  In  module  MPDMSLAVE 


Figure  6  -  Multi-Processor  Testing  of  Data  Management 
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Figure  7  -  plan  1  Conventional  Development  Tied  to  New  Military  Hardware 
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The  data  management  package  for  one  type  of  computer  architecture 
(such  as  F100L)  comprises  approximately  90  separate  modules  of 
documentation,  application  programs  and  test  programs,  running  to  250  sides 
of  paper  and  so  the  following  is  a  rather  brief  extract  to  illustrate  the  salient 
points.  Figure  3  is  a  module  called  DMTASK  which  introduces  the  concept  of 
data  management.  Figure  4  is  the  first  few  lines  of  the  module 
DMSUBSYSTEMDES,  which  describes  the  breakdown  of  data  management  in 
terms  of  parallel  co-  operating  processes.  Figures  5  and  6  are  the  first  few 
lines  of  modules  DM2TEST  and  DMTESTSYSTEM  which  give  some  indication 
of  the  test  methods  used  to  test  and  verify  itself  plus  verifying  the  underlying 
facilities  such  as  communications. 

Considering  that  there  was  no  experimental  model  of  data  management, 
we  feel  that  the  design  of  DATA  MANAGEMENT  is  in  a  reasonable  condition  after 
completion  of  integration  .  There  are  a  few  philosophical  problems 
associated  with  related  attributes  of  parameters  such  as  titles  which  would 
need  resolving  if  DATA  MANAGEMENT  were  to  be  applied  to  systems  larger 
and  more  complicated  than  those  described. 

INFLUENCE  OF  THE  PROJECT  PLAN  IN  ACHIEVING  LONG  LIFE  SOFTWARE 

Unlike  commercial  computer  systems,  military  systems  usually  require 
special  hardware  to  meet  the  severe  environment.  Unfortunately,  this 
hardware  is  not  always  readily  available  in  the  packaging  required.  If  a 
project  is  fortunate,  then  a  computer  of  the  correct  size  and  speed  will  be 
available  with  all  the  necessary  interface  cards  and  development  facilities. 

Even  so,  as  a  target  system  it  will  be  expensive,  have  a  long  lead  time  and 
be  limited  in  its  suitability  for  developing  software.  If  the  hardware  is  not 
fully  developed  then  this  must  be  added  to  the  overall  development  plan. 

The  manner  in  which  this  work  is  included  into  the  developmmt  plan  can  make 
a  great  deal  of  difference  to  the  confidence  of  achieving  the  software  targets 
set  earlier  in  the  paper.  A  common  error,  for  example,  would  seem  to  be  the 
close  dependency  of  the  hardware  and  software  parts  of  the  programme.  To 
illustrate  the  problem,  consider  two  plans  for  the  development  of  a  prototype 
multi- computer  system. 

Plan  1  -  Conventional 

Figure  7  shows  a  conventional  plan  ostensibly  designed  for  minimum 
timescale  and  material  cost.  The  problem  is  that  hardware  is  never  available 
early  enough  to  allow  the  software  testing  to  be  given  the  time  it  needs.  Often 
the  plan  will  show  a  very  short  integration  phase  but  experience  has  shown 
that  this  will  take  the  same  time  as  the  software  development.  Clearly  the 
software  programme  cannot  phase-in  communications  testing  as  early  as 
required  because  all  the  hardware  is  needed  before  a  start  can  be  made.  As 
hardware  is  usually  made  available  serially  so  the  integration  can  only  start 
at  the  end  of  the  hardware  programme.  If  the  hardware  programme  slips  there 
is  no  recovery  possible  and  the  software  testing  will  have  to  wait. 
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Plan  2  -  Decoupled 

A  major  improvement  would  be  to  decouple  the  hardware  development 
programme  and  create  a  separate  software  test  environment.  The  plan  is  shown 
in  Figure  8.  Here,  commercial  hardware  is  procured  which  will  allow  testing 
of  the  high  risk  software  areas,  namely  the  communications  and  data 
mangement  tasks.  The  applications  software  can  also  be  tested  in  a  data 
management  environment  in  a  large  processor,  and  timing  information  obtained. 
The  advantages  of  this  decoupled  approach  are: 

(a)  The  software  programme  can  be  adjusted  so  that  the  communications 

software  is  produced  first,  thus  giving  ample  time  for  the  testing. 

(b)  There  is  minimal  risk  to  that  programme  from  outside  (hardware). 

(c)  The  test  environment  can  remain  available  for  modification  proving  or 

any  parallel  work. 

It  may  be  felt  that  the  cost  will  be  higher  because  of  the  extra  hardware 
required  for  software  testing.  This  may  be  true  but  the  risk  has  been 
substantially  reduced,  not  only  to  the  software  programme,  but  to  the  hardware 
programme  as  well. 

The  hardware  part  of  the  plan  shows  an  early  evaluation  phase  to  gain 
familiarity  with  the  machine  (or  machines)  to  see  if  the  development  tools  are 
adequate,  and  to  carry  out  bench  mark  tests.  Once  the  software  design  has 
reached  the  point  where  system  parameters,  memory,  speed  and  communications 
can  be  established,  then  the  correct  machine  can  be  chosen.  Many  projects 
choose  the  machine  beforehand  and  find  great  problems  when  they  have  to 
shoehorn  the  software  in  later  on.  The  later  the  decision  on  the  processor,  the 
lower  will  be  the  risk.  The  result  of  this  revised  plan  could  be  a  slightly 
longer  and  more  expensive  programme,  but  the  plan  is  much  more  realistic 
and  the  confidence  of  achieving  a  working  system  much  higher.  The  resulting 
system  will  be  to  a  much  higher  standard.  It  will  not  be  necessary  to  find  a 
new  processor  during  development  because  the  original  one  was  unsuitable, 
and  it  is  likely  that  the  software  goals  for  quality  will  have  been  achieved. 

This  decoupled  plan  has  been  used  for  the  development  of  the  PASS, 
system,  Reference  4,  with,  in  this  case,  development  of  the  target  hardware 
not  starting  until  after  production  and  evaluation  of  a  prototype  system  using 
commercial  hardware. 

Lessons  Learnt 

Many  of  the  lessons  learnt  during  the  development  of  machinery  controls 
systems  will  have  been  learnt  by  anyone  embarking  on  the  development  of  a 
distributed  system  for  the  first  time.  The  major  problem  was  the  under¬ 
estimation  of  the  risk  and  the  unsuitability  of  the  plan.  More  material 
(Reference  8)  is  now  available  which  shows  the  standards  which  must  be  set 
in  terms  of  project  milestones  and  software  quality  assurance,  but  the  difficulty 
contractors  have  is  in  obtaining  realistic  estimates  and  assessing  the  risk 
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involved*  With  new  technology  the  planner  needs  experience  to  achieve  a 
minimum  risk  solution.  Contractors  must  heed  the  lessons  of  the  past  and  not 
propose  development  programmes  which  try  to  minimise  the  declared  time  and 
cost  but  contain  an  inherent  undeclared  risk 

The  main  lesson  learnt  during  the  Demonstrator  development  from  a 
project  plan  viewpoint  was  that  the  hardware  development  plan  was  too 
ambitious  (e.  g.  nuclear  hardening)  and  too  closely  tied  to  the  software  test 
programme,  i.  e.  the  conventional  plan  was  used.  Also  the  input/output  cards 
were  closely  tied  to  the  processor  bus,  A  separate  processor- independent  bus 
would  not  only  reduce  the  technical  problems  but  enable  different  processors  to 
be  used  with  the  same  input/output  cards.  For  the  Demonstrator  system  the 
software  structure  and  design  was  at  an  embryonic  stage  wncn  the  main 
development  contract  was  started.  Due  to  the  tight  timescales  imposed,  the 
necessary  time  required  to  resolve  fully  interface  and  structural  design 
aspects  was  not  available.  Thus  some  work  is  still  required  10  achieve  fully  the 
standards  eet,  but  additional  work  done  on  the  Data  Management  and  Message 
Routeing  packages  has  enabled  them  to  be  made  available  commercially.  A 
production  standard  has  therefore  been  achieved  in  some  areas.  With  hindsight 
an  intermediate  development  stage  would  have  been  advisable.  This,  coupled 
with  a  separate  software  test  environment  using  more  powerful  processors, 
would  have  helped  to  gain  confidence  in  the  software  design  at  an  earlier  stage. 
Too  early  were  we  constrained  by  target  hardware  and  software  limitations, 
like  memory  size  and  link  editor  table  sizes.  More  time  was  also  needed  to 
familiarise  software  producers  with  the  philosophy  and  intricacies  of  the 
design.  The  consequence  has  been  that  premature  decisions  have  been 
perpetuated,  with  the  result  that  modifications  will  be  required  in  some  areas 
in  due  course. 

Inexperience  of  software  of  this  capability  also  led  to  some  misunder¬ 
standings  of  the  software  test  philosophy  required  for  long  life  software.  It 
became  apparent,  too  late,  that  the  problems  associated  with  the  test  and 
integration  strategy  were  not  fully  understood  by  the  implementors.  The  main 
problem  was  that,  for  test  purposes,  a  ’module'  was  defined  at  too  low  a 
level.  When  modules  were  combined,  problems  in  the  overall  design  became 
clear  and  also  optimisation  was  required.  The  iterative  loop  to  correct  these 
design  problems  meant  that  re-testing  at  the  low  module  level  became  tedious 
and,  by  its  sheer  volume,  fell  into  disuse.  This  experience  confirmed  that  the 
level  of  testing  is  one  of  the  most  difficult  decisions  taken  during  a  project. 
With  the  right  level  of  module  for  testing  and  then  automating  as  much  as 
possible,  re- testing  after  modification  is  encouraged  and  labour  costs  are 
reduced.  To  achieve  this  requires  a  well  thought  out  software  development  plan 
and  some  previous  experience.  Again,  an  intermediate  stage  would  have  helped. 

CONCLUSION 

The  software  design  for  future  systems  has  been  thought  out  with  a  view 
to  minimising  support  and  increasing  reliability.  The  recommended  approach 
is  to  use  a  modular  design  which  eases  configuration  control  and  to  automate 
as  much  as  possible.  This  approach  allows  advantage  to  be  taken  of  future 
advances  in  technology  and  will  enable  more  fully  integrated  ship's  systems 
to  be  produced  in  the  future. 
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The  traditional  approach  to  system  development  which  includes  hardware 
and  software  design  and  manufacture  in  parallel,  and  culminating  in  a  long 
period  of  integration  (typically  50%  of  the  overall  tirr  escale),  needs  to  be 
re-assessed  To  give  confidence  to  the  system  specifiers  that  digital 
technology  is  not  a  high  risk  solution,  the  problem  areas  need  to  be  identified 
and  resolved  as  early  in  the  programme  as  possible.  It  is  suggested  that 
decoupling  the  hardware  and  software  programmes,  whilst  possibly  increasing 
the  apparent  timescale  of  the  overall  programme,  would  reduce  the  risk  of 
over- run  and  cost  escalation. 

The  development  work  so  far  shows  th  ,t  there  has  been  substantial 
progress  achieved  in  meeting  the  design  objectives  and  in  understanding  the 
management  of  computer-based  development.  Early  experience  of  support  of 
the  software  shows  that  the  effort  expended  in  achieving  the  design  objectives 
of  reliable  and  maintainable  software  has  been  justified  and  will  be  repaid  many 
tin  es  over  in  the  future. 
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A  PAST  AND  CLEAN  COLLISION  AVOIDANCE  MANOEUVRE 


■by  Cornelia  DeWit  , 

Delft  Univ.  of  Techn.,  Dept*  of  Mathematics. 

0, ABSTRACT. 

Let  A  and  B  be  two  course  crossing  ships  under  way  with  a  danger  of 
collision.  Applying  rules  15  and  17  of  the  International  Regulations 
for  Avoidance  of  Collisions  at  Sea  (IRACS),  let  A  be  obliged  to  take 
evading  action,  while  B  is  initially  obliged  to  maintain  course  and  speed. 

Denoting  A* a  and  B’s  positions  at  time  t  as  3c(t)  and  i(t)  ,  the  co- 
-ordinate  axes  are  so  selected  that  -  see  figure  1  - 

(i)  A  is  at  the  origin  at  time  t  -  0,  bo  x(0)  -  £  and 

(ii)  A  is  approaching  steadily  along  the  X^-axis,  so 

i(0)  -  (va(0)  0)'  ,  S(0)  -  0  . 


Figure  1. 

Two  course  crossing  ships  A  and  B  with  a  danger  of  collision 


A* b  collision  avoiding  manoeuvre  (c.a.ro.)  will  consist  of  a  certain 
rudder  angle  input  { 6 ( t ) J  with  a  constant  full  power  propellor  thrust. 
lMt)l  is  defined  by 
6(t)  -  0°  f or  0  4  t  <  t7, 

&(t)  -  +  20°  (starboard  helm)  for  S  t  <  t^  , 

6(t)  •  -  20°  (or  -10°  occasionally)  for  t?  S  t  <  , 

6(t)  -  +  20°  for  tj  S  t  <  t^  , 

6(t)  -  -  20°  for  t  *  t  <  t5  # 

6  ( t )  -  0°  for  te  t$  . 
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At  time  t,-  A  should  be  back  on  her  former  track,  heading  her  former 
course,  A track  as  a  result  of  this  rudder  input  xs  shown  in  figure  2. 
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Figure  2, 


At  time  t_  A  has  a  certain  arrearage  d  to  the  position  that  A  would 
have  had  without  the  c.a,m,: 

d  -  x*(t^)  -  x^t^)  with  x?(t5)  =  x1  (0)  +  vft(0)  *5  • 

This  arrearage  d  is  needed  for  A  to  keep  sufficiently  clear  from  B, 

This  paper  presents  an  algorithm  to  evaluate  this  needed  arrearage  and 
the  corresponding  switching  times  t^  t^  etc. 

If  d  appears  to  be  too  large,  the  c.a.m,  consists  of  a  sufficiently 
wide  loop  around  B's  stern. 

The  entire  procedure  was  preprogrammed  for  a  given  ship  with  known 
dynamics.  This  program  waB  tested  on  a  wide  variety  of  cases, 

1,  INTRODUCTION. 

Consider  the  following  situation,  occurring  in  open  sea  with  a  good 
visibility. 

At  time  t  »  0  the  own  ship  A  has  detected  a  course  crossing  ship  B 
with  a  danger  of  collision.  B  is  approaching  at  a  constant  relative 
velocity  of  magnitude  v  and  direction  ar  ,  B's  relative  bearing  f 
as  seen  from  A,  is  less  ^Ehan  two  points  aft  the  beam,  i.e, 

4°  <  9b  <  112.5°  . 

Prior  to  t  -  0  ,  a  radar  plot  has  been  made,  revealing  that  B's  distance 
of  closest  approach  r  .  is  less  than  a  preset  value  rQ  ,  leading  to  the 
conclusion  that  theremii  a  danger  of  collision. 

In  the  given  situation  A  is  obliged  to  take  evading  action  while  B  is 
initially  obliged  to  maintain  course  and  speed.  (The  quantities  vr> 
and  rmin  are  shown  in  figure  1.) 

In  a  recent  paper  -  Bee  [l ]  -  a  method  was  presented  to  evaluate  a 
"time  optimal  collision  avoiding  manoeuvre".  This  method  had  the 
following  characteristics, 

(l)  The  ship’s  dynamics  were  modelled  by  the  following  set  of  differential 
equations  i 
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*1 

»  u^  cos 

»  -  u2 

sin  T  , 

(1.1. a) 

x2 

-  u1  sin 

T  +  *2 

cos  f  , 

(1.1. b) 

V 

•  0) 

( 1 . 1 .  c ) 

li 

■  -  a  u> 

-  b  w5 

+  c  b  , 

(1.1. d) 

“  “  f  U1 

-  W  u2 

+  S 

(  1  •  1  .  6  ) 

U2 

-  -  r^  u 

, 

(1.1.*) 

x*  »  *  »l 

Notations  *  x  »  (x^  x^)  ,  x  «  x2;  :  A's  position  and  velocity, 

?  ,  q  %  A’s  course  and  rate  of  turn  , 

,  u2*  A’s  forward  and  starboard  beam  velocity  • 
b  i  rudder  angle  • 

All  of  these  quantities  are  shown  in  figure  }  , 

(2)  To  avoid  collision,  A  carries  out  a  bang-bang  rudder  manoeuvre  {&(t)j, 
the  graph  of  which  is  shown  in  figure  4  • 


Figure  4. 
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The  numerical  algorithm  to  evaluate  t^  ,  t^  etc.  was  tested  on  a  number 
of  cases.  The  outcome  of  these  tests  gave  rise  to  a  subdivision  into 
two  classes. 

(a)  In  most  cases  the  starting  time  t^  appeared  to  be  as  early  as  possible 
The  entire  loop  was  described  way  ahead  of  the  time  of  closest 
approach.  Figure  5  gives  a  view  of  the  evading  procedure  in  this  case. 


Figure 

As  a  result  of  A's  delaying  manoeuvre 
B  passes  well  ahead  of  A. 


(b)  If  B  is  approaching  from  a  direction  close  to  the  bow,  the  c.a.m. 

is  postponed  until  a  later  time,  resulting  in  an  evading  loop  around 
B's  stern.  Figure  6  shows  wh«*t  principally  happens. 
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We  shall  now  pay  some  more  attention  to  case  (a).  For  times  t  gt  the 
ship  is  back  on  her  former  track*  however  with  a  certain  arrearage5* 

d(t)  -  x*(t)  -  Xl(t)  with  x*(t)  -  va(0)  t  .  (1.5) 

(va(0)  !  A's  speed  at  time  t  -  0.) 

This  arrearage  enables  A  to  let  the  other  ship  B  pass  ahead  of  her  at  a 
sufficient  distance.  Reversing  this  argument,  we  can  evaluate  dR  *»s  a 
necessary  arrearage  to  guarantee  a  closest  distance  from  A  to  B  at  the 
amount  of  r  at  least.  Setting  the  starting  time  as  early  as 

possible  -  ii?  this  study  I  selected  -  1  min,  -  this  value  dn  and 
the  "final  loop  conditions"  (1,2)  can  be  used  to  determine  the  switching 


times  t_ 


and 


2  •  u3  ’  4  5  * 

According  to  the  dynamic  model  as  well  as  to  practical  experience,  the 
ship’s  forward  speed  at  time  has  not  yet  regained  its  former  value 

v  (0)  •  Properly  speaking,  this^means  that  we  have 


for  t  >  tc 


d(t)  >  d(t5)  . 


0.4) 


So  if  we  set  a  lower  bound  to  d(tj-)  to  guarantee  a  certain  clear 
distance  r  at  a  later  time,  counting  on  an  arrearage  equal  to  d(tc)  , 
the  actual  clear  distance  will  be  greater  than  rQ  •  5 

2.  SOME  DETAILS  OF  THE  MODIFIED  DYNAMIC  MODEL. 


Compared  to  the  dynamic  model  that  was  used  in  the  first  study,  a  few 
modifications  were  applied. 

In  the  first  place  the  rudder  angle's  coefficient  c  in  (l,1,d)  was 
replaced  by  # 


1 


2  1 


This  means  that  we  take  account  of  a  decrease  in  the  turning  moment, 
caused  by  the  speed  reduction,  which  in  its  turn  is  a  result  of  the 
ship's  rate  of  turn. 

Secondly  aQmaximal  rudder  angle  of  35°  is  rather  unpractical  in  open  sea. 
We  used  20  as  a  maximum  for  | 6 ]  instead. 

The  dynamic  model  can  now  be  worked  out. 


X1  * 

cos 

+  (r^  w  + 

J>) 

sin 

*  » 

(2.1 

.a) 

*2  - 

u1  sin 

f 

+ 

3 

j-T 

i 

r5  w5) 

cos 

*  > 

(2.1 

•  b) 

?  - 

w 

t 

(2.1 

•  c) 

u  * 

-aw 

- 

b  w^  +  (c^ 

*  C2 

«,) 

&  , 

(2.1 

.a) 

U1  ’ 

- f 

- 

W  w2  4-  S 

. 

(2.1 

•  e) 

Units  *  times  in  minutes,  lengths  in  nautical  miles,  angles  in  radians. 

This  dynamic  model  Corresponds  to  a  9  000-tons  cargo  carrier  with  a 
service  speed  of  15  knots. 

Expressed  in  the  appropriate  units,  the  various  parameters  were  given 
the  following  values  : 


0.0375 


0  ,  a 


0.86  ,  S  -  0.215 


1.084  ,  b  -  0.62  ,  c 
0.07  . 


1 


10.212 
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The  15  knots’  service  speed  means  an  initial  value  for  u^  of  u.j(0)*»  0*25* 

Defining  the  "smoothened"  signum  function  as 

sig(t)  .  t/(t2  +  10'4)^  ,  (2.2) 

the  following  function  was  selected  for  the  rudder  angle  ; 

4 

6(t)  «  0.0875(sig(t-t1+G.l)+l)(sig(tI--t-0.l)  JT  sig( t .-t+0.2)  •  (2.3) 

5  i=2  1 

Figure  7  shows  the  graph  of  this  function  for  an  arbitrary  set  of 
values  for  until  « 


Figure  7» 

Graph  of  the  ruaaer  angle  function  6 ( t ) 

with  *  1  >  t2  “  2.3  f  *  p.8  ,  *  8  ,  -  8.7  . 

Adopting  this  function  implies  the  assumption  that  it  tgkes  0,4  minutes 
or  24  seconds  to  move  the  ruuder  from  £  20  to  —  20  . 

3.  EVALUATION  OF  THE  C.A.M.'S  CnAHACTEHISTICS  , 


For  the  time  being  we  shall  shift  the  origin  to  t.  ,  If  we  now  select 
tg»  t^,  t  and  t  ,  the  set  of  differential  equations  (2.1)  can  be 
numerically  integrated,  using  the  ruuder  function  as  given  by  (2.243) 
and  taking  as  initial  conditions 


x^O)  =  x2(0)  -  ?(0)  *  u(0)  -  0  ,  u1  (0)  *  0.25  . 

The  outcome  is  a  set  of  values  for  x.  ,  x2  etc,  at  time  • 

Far  an  arbitrary  value  of  -  within  a  certain  range  -  the  values  of 
t y  and  are  implicitly  determined  by  the  final  conditions 

x2(t^)  -  *(t5)-  w(t^)  »  0  . 

The  following  lines  ere  a  brief  description  of  a  method  to  evaluate  t*  # 

+.  anH  +.  ^ 

z  -  (y1  y2  and  taJcine 

t4  *  +  A  *  t5  “  h  *  y3  *  0.1.a,b,c) 

the  final  values  of  x2  ,  f  and  u  become  functions  of  ^  .  Defining 

Hi)  -  (x2(t5))2  +  (?(t,-))2  *  («(t5))2  ,  (5.2) 

we  can  find  the  appropriate  value  jr  -  satisfying  f(;jr)  ■  0  -  by  means 
of  minimization  of  f  with  a  minimizing  procedure. 
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Introducing  a  vector 
2 


This  minimization  was  carried  out  for  -  1(0*25)2  *  After  each  mini- 
-mization  th  rrearage  d  at  time  was  also  evaluated  * 

d  -  0.25  t5  -  Xl(t5)  .  (5.5) 

The  result  is  exposed  in  table  I  « 

Table  I  , 


h 

(t^  in  minutes,  d  in  nautical  miles) 
t2  t,  t4  t,  * 

0 

1 

5*16 

4.60 

5.22 

0.25 

0 

1.25 

3.98 

5.79 

6.46 

0.37 

0 

1.5 

4.81 

6.98 

7.67 

0.55 

0 

1.75 

5.60 

8.15 

8.90 

0.78 

0 

2 

6,51 

9.55 

10.02 

1*09 

Applying  the  least  square  residuals  technique,  these  results  can  be  well 
enough  represented  by  the  following  set  of  interpolating  formulae,  valid 
for  an  arbitrary  value  of  t*  • 


t2  »  (0.4915 


f 


1,7828  d 
2 


0.25165  )/0.89U  +  t1  f 


t,  -  0*l6(t2  -  ♦  2.848(t2  -  t1 )  +  0.16  , 


4  «  0.0686( t2  -  t,T 


4.5625(t2  -  -  0.0265  + 


-  0.25l4(t2  -  t^r  +  5*5705(t2  -  -  0.1045  +  t1 


(5. 4. a) 

(3.4'b) 

,  (5.4.C) 
•  (3.4.d) 


Figure  8  shows  the  graphs  of  5{t)  ,  ?(t)  f  w(t)  and  u^(t)  for  a  c,a.m, 
loop  with  «  1  and  t-  •  2,5  . 


Figure  8, 

6  :  ruduer  angle  (degrees) 

¥  :  course  deviation  from  schedule  (degrees) 

(j)  s  rate  of  turn  (degrees/minute) 

*  ship’s  forward  velocity  (knots) 
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4.  EVALUATION  OP  TEE  NEEDED  ARREARAGE 


At  the  start  of  the  procedure,  the  following  quantities  are  assumed  to 
be  known  : 

r  t  lower  bourl  for  the  allowed  closest  mutual  approach, 
dQ  t  initial  value  of  the  distance  AB  ,  dQ  -  |  |x(°)  I  I  * 

:  B's  telative  direction  as  seen  from  A  at  time  t  *=  0  , 
vr  i  B's  relative  speed  at  time  t  =  0  f 
*  B's  relative  course  at  time  t  -  0  . 

* 

a  2  fir  -  n  , 

r  r  f  # 

so,  with  Ax^  =*  (  Ax1q  Ax2q)  ”  Xq  “  We  *lave 

Ax.  =»  v  cos  a  ,  Ax~  »  v  sin  a  • 

1o  r  r  1  2o  r  r 

We  further  denote 

rminx  ^fcast  distance  from  A  to  B,  assuming  that  both  vessels  maintain 
their  course  and  speed, 

r  :  B's  distance  to  A  when  crossing  A’s  rhumb  line  without  a  c*a#m. 
This  initial  situation  is  shown  in  figure  9, 


j 


{ 

i 

I 

f 


Figure  9, 


It  is  now  clear  that 


rBin-  do  sin(8r  -  *b> 

ro  *  rmin/sin  “r  * 

* 

Remark  t  r  .  and  r  follow  the  sign  of  « 
min  c  r 

rc  are  negative,  if  «r  <  ,  i*e, 

behind  A's  stem. 


(4.1) 

(4.2) 

-  *b  •  So  rmin  and 
if  B  would  have  passed 
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After  having  described  an  evading  loop,  we  assume  that  A  has  regained  her 
former  speed.  Now,  with  A  and  B  both  proceeding  in  the  old  directions  with 
the  old  speed,  B’s  relative  velocity  has  also  regained  its  old  value.  This 
means  that  B’s  relative  track  for  A  is  a  straight  line,  that  intersects 
A* a  track  at  an  angle  a*  .  (See  figure  10) 

In  order  to  keep  sufficiently  clear  from  B,  A  should  have  a  distance  r 
to  B's  relative  track. 


Figure  10. 

So  at  the  time,  when  B  crosses  A's  course  line  at  C,  A's  distance  to  C 
should  be  increased  from  rc  -  before  the  (t.  -  t,.)-loop  -  to  r  /sin  a* 
after  the  evading  loop.  Thus  the  needed  arrearage^is  °  r 

dn  -  ro/sin  «*  -  r0  .  (4.5) 

5. THREE  AVOIDING  STRATEGIES . 

Considering  the  (t^t  )-loop,  the  ship's  maximal  deviation  from  her 
original  course  grows^rapidly  for  increasing  values  of  d  .  We  therefore 
set  an  upper  limit  to  d  at  the  amount  of  0.7  nm.  This  corresponds  to 
a  maximal  change  of  heading  of  55  * 

We  thus  come  to  the  proposal  of  three  evading  strategies. 

(1)  If  the  necessary  arrearage  in  track  for  A  to  keep  clear  from  B  is  not 
greater  than  0.7  nm,  we  follow  strategy  No.1  : 

If  d^  S  0*7  then  Strat.  No.1  .  (5,1 ) 

The  c.a.m.  starts  at  »  1  min.  The  switching  times  t^  until  can 

then  be  evaluated  from  formulae  (3.4.a)  to  (5»4*d),  For  pragmatic  reasons, 
these  values  are  rounded  off  to  the  nearest  tenth  of  a  minute. 

If  the  necessary  arrearage  appears  to  exceed  this  0*7nn>-limit,  we  select 
one  of  the  strategies  No. 2  or  5,  depending  on  whether  or  not  r  is 
positive.  Stated  formally  : 
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If  >  0.7  &  rmin  -  0  then  Strategy  No, 2  and  (5*2) 

If  dn  >0.7  &  <0  then  Strategy  No.}  .  (5*3) 

Before  describing  these  strategies,  we  have  to  define  tmin  as  the  time, 
when  A  and  B  would  have  had  their  closest  approach  r  .  without  any 
evading  manoeuvre.  This  moment  follows  from 


t  .  *  d  cos(a*  -  )/v  . 

nun  o  v  r  M3  r 

(5.4) 

(2)  We  shall  now  specify  Strategy  No,  2: 

*1  =  ‘min  "  4  > 

(5. 5. a) 

t2  =  t,  +  1.5  , 

(5.5. b) 

tj  -  t,  +  4.8  , 

(5.5.c) 

*4  *  *1  +  7 

(5.5.d) 

*5  *  *1  *  7‘7  * 

(5.5.e) 

The  rudder  angle  signal  is  +  20°  for  5  t  <  t^  4  t^  5  t  <  t^  and 

-  20°  for  t,  S  t  <  t.  &  t,  S  t  <  t,  . 

2  3  4  5 


(3)  If  r  .  is  negative,  we  make  a  wider  loop  around  B’s  stern,  because  B 
would^ave  passed  closely  behind  A  without  an  evading  manoeuvre.  We 
achieve  this  by  selecting  a  rudder  angle  of  -  10  during  the  time 
interval  between  t^  and  ty  The  switching  times  are 


“1  "  min  *  *  *  w*-*^ 

t2  -  t1  ♦  1.5  ,  (5.6.b) 

*}-*!+  7.4  ,  (5.6-c) 

t4  -  t,  +  9. 7  ,  (5.6.d) 

t5  -  t,  +  10.5  .  (5.6.e) 


The  rudder  angle  signal  is  identical  to  the  values  in  Strategy  No, 2 


for  the  time  intervals  [tjftg)  >  [t^,t^)  and  [t^,t^).  However  for 
tg  *5  t  <  tj  the  rudder  angle  signal  is  -  10°  • 


Concerning  the  other  ship  B,  her  true  track  »nd  motion  are  not  relevant 
when  it  comes  to  deciding,  which  of  the  three  evading  strategies  is  to 
be  selected.  However,  when  the  entire  evading  manoeuvre  is  precalculated, 
it  is  also  important  to  calculate  the  time  behaviour  of  the  relative 
position  vector 

Ax(t)  -  £(t)  -  x(t)  ,  (5,7) 


We  therefore  need  to  know  B's  -  assumed  to  be  constant  -  true  motion  £  , 
characterised  by  its  magnitude  and  its  direction  a.  . 

Considering  the  triangle  of  steady  velocities,  shown  in  figure  11,  we 
can  easily  derive  these  quantities  from  the  following  formulae  i 

h  -  v^  sin  a*  ,  p  «  v^  cos  a*  ,  (5,8.a&b) 

P1  -  arc tg(p/h)  ,  P2  -  arctg((0.25-p)/h)  ,  (5*S*c  &  <0 

“b  -  °r  +  P1  +  P2  .  vb  -  f((0.25  -  p)2  +  h2)  .  (5.s.e  4  f) 
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6, EXAMPLES. 


Figure  11. 


In  this  paragraph  three  worked  out  examples  are  presente^  of  each  of  the 
three  evading  strategies.  A’s  course  is  taken  equal  to  0  and  A's  initial 
speed  is  15  knots,  so  v  (0)  -  0.25  .  For  the  safety  boundary  of  the 

minimal  mutual  distance  the  value  r  *  0.5  nm  was  selected, 

o 

Example  1  :  (See  figure  12) 

At  5  run  distance  from  A,  B  is  approaching  from  a  direction  9^  -  60°  with 
a  relative  course  *  258°  and  a  relative  speed  vf  *  0.25  nm/min. 

Using  (4.1)»  (4.2)  and  (5.4)  we  find 


r  .  - 

mm 

From  formulae 


-  0,18  , 
(5.8. a)  to 


%  -  299° 


(5.8.f )  we  can  conclude  that 
,  v,  «•  0,242  (corresponding  to 


14,5  knots). 


The  necessary  arrearage  follows  from  (4.5)  *  d^  ■  0.56  •  In  view  of  (5.1) 
we  use  strategy  No.  1,  so  =  1  .  With  (5. 4, a)  to  (5*4»d)  we  find 


tg  m  2.5  ,  t^  "  5*8  ,  t^  «8  ,  t^  ■  8.7  . 


Evaluating  A’s  and  B's  expected  tracks,  we  find  a  minimal  distance  of 
0.54  nm.  Figure  12  shows  these  tracks  as  well  as  B’s  relative  track,  as 
seen  on  A’s  radar  screen,  if  it  is  working  in  the  "true  bearing  &  rela- 
-tive  motion ’-mode. 
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♦ 


Example  3  *  (see  figure  14 ) 


Like  in  the  previous  case,  the  approaching  angle  r  is  rather  small  in 
this  example,  so  the  arrearage  is  too  large  to  be  realistic.  Moreover, 
r  in  and  rc  are  negative,  so  that  the  evasion  is  carried  out  according  to 
tSe  third  strategy.  Numerical  details  of  this  example  can  be  found  in  the 
captions  to  figure  14. 

W 


5  nra  , 


Figure  14. 

=  198  ,  v  «  0*45  nm/min  *  27  knots, 


rmin““° " 1  ^  rc«-0,56  nm,  dR  «  1,54  nm,  ,^-218  »vb»13,6  kn. 

Strategy  No,  3  : 


7*1 
8.61 
14.5" 
16.8“ 
17. 6m 


min 


»(t) 

5(t) 

6(t) 

6(t) 


0 

+  20° 
-  10° 
+  20° 


6(t)  =  -  20° 

'  5(t)  *  0° 

Expected  closest  approach  0,41  nm  at  time  t* 
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7.  CONCLUDING  ..EMARKS, 

In  quality,  the  adopted  model  for  the  ship* a  behaviour  has  been  found 
valid  for  a  wide  variety  of  ship  types,  from  coastwise  traders  to  large 
tankers,  (See  [2]).  Of  course,  the  various  parameters  r^ ,  r^,  a,  b  etc. 
can  differ  considerably. 

Once  these  parameters  are  known,  one  can  adopt  reasonable  values  for  the 
various  input  parameters  and  things  can  be  entirely  precalculated  off  line 
for  a  given  ship. 

Using  these  precalculations  and  counting  on  the  present  state  of  the  art 
regarding  possible  computer  facilities  for  on  line  operations,  the  neces- 
-sary  collision  avoiding  manoeuvre  can  be  very  well  calculated  within  a 
few  seconds,  however,  the  author  wishes  to  express  his  neutrality  regar- 
-ding  the  question,  if  the  manoeuvre  should  be  carried  out  by  hand  or 
automatically. 

REFERENCES 

[1  ]  C.  de  Wit  &  J.Oppe  , 

Optimal  Collision  Avoidance  in  Unconfined  Waters, 

Navigation  (U.G.A.),  Vol.26,  No. 4,  1979/80,  p.  296  -  30}  . 

[2]  G.  van  Leeuwen, 

A  Simplified  Nonlinear  Model  for  a  Manoeuvring  Ship, 

Report  No, 262,  Naval  Architecture  Department,  Delft  Univ,  of  Techn. 


C  1-15 
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ABSTRACT 

A  radar  simulator  is  newly  designed  and  implemented.  This  simu¬ 
lator  generates  targets  up  to  eight  ships  automatically  which  move  pro¬ 
babilistically  under  computer  control.  The  simulator  deals  with  two 
models  oi  target  ships'  movements.  One  is  to  simulate  ships  passing 
through  a  narrow  channel.  Another  is  to  simulate  the  situation  such 
that  an  own  ship  encounters  with  targets  at  all  times,  which  purpose 
Is  trainings  of  collision  avoidance  by  use  of  a  radar  indicator.  The 
situations  are  effectively  produced  by  some  specified  probabilistic 
variables.  Hence,  the  trainings  are  not  restricted  by  time,  and  the 
management  of  the  situation  difficulty  on  training  is  relatively  easy. 

INTRODUCTION 

The  role  of  the  electronic  nautical  instruments  is  much  important 
for  safe  navigation  in  the  environment  that  vessels  become  large  and 
fast  and  ship  operations  are  fairly  automated  in  recent  years.  Espe¬ 
cially  the  radar  is  an  essential  equipment  on  large  merchant  ships  ac¬ 
cording  to  the  provision  of  the  law,  and  in  addition  to  improvements 
of  radar  navigators  are  required  to  have  enough  skill  In  dealing  with 
it.  As  a  result,  many  kinds  of  radar  simulators  have  been  developed 
as  the  simple  and  efficient  trainers  on  the  ground  and  now  the  STCW 
convention  requires  radar  simulator  training  to  navigators(l) . 

In  this  paper,  we  propose  a  simulation  technique  of  radar  simula¬ 
tor  in  which  the  movements  of  targets  on  the  radar  indicator  are  prob¬ 
abilistically  controlled  by  a  computer.  The  probabilistic  method  is 
profitable  to  generate  situations  automatically  and  eternally.  In  com¬ 
parison  of  a  radar  simulator  using  this  method  with  the  conventional 
ones  whose  situations  are  set  up  by  manual  or  by  scenario  as  choosing 
one  of  situations  prepared  beforehand,  this  new  simulator  has  charac¬ 
teristics  that  it  is  able  to  perforin  self-training  and  to  evaluate  gen¬ 
erated  situations  by  statistic  parameters. 

THE  OUTLINE  OF  SIMULATOR  ARRANGEMENTS 

The  radar  simulator  is  illustrated  as  a  block  diagram  in  Fig.  1. 
The  installation  consists  of  three  parts;  the  first  is  equipments  in 
a  simulator  room  to  manipulate  the  simulator  and  to  display  the  visual 
data,  the  second  is  the  hybrid  computer  to  control  the  simulator,  and 
the  third  is  the  interfaces  between  the  computer  and  some  visual  equip¬ 
ments  . 

The  digital  part  of  the  general  purpose  hybrid  computer  has  a  main 
memory  of  16  K  words  (16  bits  word),  and  the  standard  execution  time 
is  2  u  sec.  As  Input  and  output  devices  of  the  computer,  there  are  a 
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line  printer,  a  card  reader,  a  cartridge  disk  unit  and  a  console  which 
is  a  graphic  display  of  storage  tube  type  with  a  hard  copy  unit.  In  the 
analogue  part  (including  interface  units  between  the  analogue  unit  and 
the  digital  unit),  it  is  able  to  execute  analogue  arithmetics,  A/D  and 
D/A  conversions  and  logical  arithmetics.  On  the  simulator  in  mock-up 
bridge  a  trainee  is  able  to  manipulate  a  steering  wheel  and  an  engine 
telegraph  and  also  is  able  to  look  at  repeater  compasses,  an  engine 
r.p.m,  indicator,  a  rudder  angle  indicator,  a  ship  speed  meter  and  a 
standard  radar  indicator  which  is  now  possible  to  display  maximum  eight? 
targets  but  not  to  display  coast  lines  in  the  absence  of  hardware  units. 


Repeater  Compass 
&  Indicators 


Eng.  Telegraph 


Wheel  Stand 


Radar  Indicator 


Figure  1.  A  Block  Diagram  of  A  Radar  Simulator. 


PROCESS  ON  THE  COMPUTER 
The  Outline  of  Process 

Signals  sent  from  the  computer  for  the  radar  indicator  end  other 
nautical  instruments  are  required  to  be  analogue  by  the  hardware  restic- 
tion.  Owing  to  the  hybrid  computer,  it  is  relatively  easy  to  transfer 
or  convert  various  information  between  simulator  equipments  and  the 
computer , 

The  input  analogue  signals  for  ship  control  are  of  an  ordered  rud¬ 
der  angle  from  the  steering  wheel  and  of  an  ordered  engine  r.p.m.  from 
the  engine  telegraph.  The  output  analogue  signals  are  of  respcnsed  mo¬ 
tions  that  are  rudder  angle,  engine  r.p.m.,  ship  speed,  heading  angle, 
rate  of  turn  and  own  ship  position,  and  furthermore  targets’  positions 
and  the  serial  pulse  signals  to  control  pulse  motors  of  repeater  com¬ 
passes.  These  input/output  signals  are  converted  analogue  to  digital 
or  digital  to  analogue  in  the  analogue  part  cf  the  hybrid  computer 
which  is  used  as  one  of  interfaces  in  this  simulator  system.  The  other 
controls  of  simulation  processes  are  done  in  the  digital  part,  because 
the  software  programming  is  much  advantageous  to  develop  and  maintain 
rather  than  the  analogue  patching. 
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In  a  ship  handling  simulator  system(2)  a  calculation  cycle  of  dig- 
4"sl  computations  is  desired  to  be  less  than  0.2  sec  In  order  to  drive 
visual  displays  using  pulse  motors  smoothly.  Therefore  the  cycle  of 
the  radar  simulator  is  now  set  to  be  0.1  sec  in  consideration  of  incor¬ 
poration  with  the  ship  handling  simulator  in  future. 

Here  the  contents  of  processes  at  the  digital  part  are  shown  ex¬ 
cept  the  control  of  targets.  The  simulation  program  is  devided  into 
three  modules;  a  preparation  module,  a  main  loop  module,  and  a  termi¬ 
nation  module  respectively. 

The  first  module  for  preparation  works  in  card-reading  of  initial 
data,  calculation  of  initial  values,  recognizing  status  of  operational 
buttons  on  the  control  stand,  and  preparation  of  recording  of  the  sim¬ 
ulation  process.  Especially  in  setting  of  initial  conditions,  auto¬ 
matic  setting  of  targets  on  the  display  is  one  of  the  characteristics 
of  this  simulator.  But  full-automatic  setting  will  restrict  reproduc- 
tibity  end  f lexlsibility  of  traffic  situations  and  then  the  increase 
of  fltr.i sibil ity  will  force  an  operator  to  do  troublesome  works  of 
target  setting.  Therefore,  the  initial  data  are  given  by  the  following 
three  ways; 

1)  The  initial  values  on  the  simulation  program:  they  contains  system 
constants  of  the  simulator  and  fixed  default  values  for  some  variables. 

2)  Inputs  from  card  reader:  these  are  used  to  specify  statistical  prop¬ 
erties  of  targets.  The  simulator  offers  five  kinds  of  own  ship  types, 
and  the  type  is  specified  by  the  values  on  cards. 

3)  Inputs  from  console:  these  give  the  initial  values  of  pseudo  random 
number  sequences  for  the  probabilistic  target’s  generation. 

On  the  second  module  for  main  loop,  there  are  three  kinds  of  loop- 
periods  ,  namely ,  o.l  sec,  1  sec,  and  60  sec.  The  following  processes 
have  the  periods  denoted  in  the  brackets. 

1)  Calculation  for  own  ship  movement[G,l  sec]:  own  ship  motion  is  ass¬ 
umed  to  obey  che  second-order  differential  equations  proposed  by 
Nomoto( 3) . 

2)  Calculation  for  present  target’s  positions  on  the  radar  indicator 
[0.1  sec]. 

3)  Transmission  of  data  of  1)  and  2)[0,1  sec]:  calculated  logical  data 
for  the  radar  indicator  and  others  are  converted  into  appropriate  volt¬ 
age  levels,  and  transmitted  to  them.  And  serial  pulse  signals  are  alsc 
transmitted  to  a  pulse  motor  for  the  bearing  control  of  own  ship’s  head. 
^ )  Generating  targets  discussed  in  the  next  section[60  sec]. 

5)  Recording  the  simulation  process[l  sec]. 

On  the  third  module  for  termination,  various  equipments  are  recov¬ 
ered  to  initial  statuses,  and  the  file  of  records  of  simulation  is 
closed  when  the  simulation  terminates  normally. 

Most  of  routines  of  the  simulation  program  are  described  in 
FORTRAN,  and  the  total  size  cf  them  is  about  1000  steps  in  source  form 
and  13  K  words  in  executable  form. 

Recording  Simulation  Data 

The  simulation  data  are  available  for  evaluations  of  trainings,  of 
some  criterions  for  collision  avoidance,  and  so  on.  Gathering  of  data 
is  entirely  carried  out  on  the  computer  side  and  their  output  devices 
are  a  line  printer,  a  graphic  display  and  a  disk  cartridge;  we  call 
them  as  logging  data,  tracking  data  and  disk  data,  respectively.  The 
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formers  are  used  for  monitorings  on  a  simulation,  and  they  are  numeri¬ 
cal  records  and  visual  records.  The  last  is  gathered  for  the  sake  of 
some  analysis  after  the  simulation. 

Therefore  disk  data  must  be  effective  for  the  reproduction  of  a 
simulation,  and  the  evaluation  of  trainings;  for  example  the  DCPA  ( 
Distance  of  Closest  Point  of  Approach)  and  the  TCPA  (Time  of  Closest 
Point  of  Approach)  are  probably  used  for  the  analysis.  Of  course  the 
output  of  these  data  in  real  time  makes  it  possible  to  evaluate  a 
training  on  the  instant.  Contents  of  these  data  are  shown  in  Table  1, 
where  the  value  in  brackets  denotes  the  time  interval  of  output. 


Table  1.  The  Contents  of  records 


Data  type 

_ 

Contents 

Logging  data 
[1  min] 

Elapsed  time; 

Absolute  position.  Speed,  Course  of  own  ship; 
Relative  position.  Speed,  Course,  DCPA, 

TCPA  of  each  target 

Tracking  data 
[^sec/target ] 

Trace  of  each  target  on  graphic  display 
with  identifier 

Disk  data 
[10  sec] 

Elapsed  time; 

Absolute  position.  Speed,  Course,  Turn  rate. 
Rudder  angle,  Rudder  speed.  Engine  r.p.m. 
of  own  ship; 

Relative  position,  Speed,  Course,  DCPA,  TCPA 
of  each  target 

THE  CONTROL  OF  TARGETS 
On  the  Probabilistic  Method 

Generally,  generations  and  movements  of  targets  on  the  radar 
indicator  are  important  and  difficult  problems.  In  conventional  simu¬ 
lators  whose  purpose  are  mainly  trainings  of  collision  avoidances, 
situations  of  targets  arrangement  are  specified  by  manual  or  scenario. 
It  is  considered  that  these  methods  are  favourable  to  generate  the 
intended  and  restricted  situations  in  some  limited  time  intervals,  but 
that  they  have  some  problems  to  continue  trainings  or  experiments  for  a 
long  time  and  so  on.  For  example,  undesirable  times  are  spent  for 
setting  the  situations  and  moreover  one  of  more  important  things  is 
that  it  i s  comparatively  difficult  for  conventional  methods  to  change 
the  grade  of  situations  continuously(  *0 . 

The  number  of  ships  passing  through  a  fairway,  the  time  intervals 
of  them,  and  positions  passing  through  a  channel  are  considered  to  obey 
simple  probabilistic  distributions( 5,6) .  In  view  point  of  these  laws 
the  simulator  px jposed  in  this  paper  is  designed  to  be  able  to  generate 
and  also  change  the  traffic  situations  such  that  each  target  is  subject 
to  some  probabilistic  variables  based  on  statistic  properties.  Fortu¬ 
nately  it  is  easy  for  this  method  to  control  the  situations  automati¬ 
cally  by  a  computer.  In  the  generation  of  probabilistic  variables,  the 
computer  creates  pseudo  random  number  sequences  by  the  multiplicative 
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congruence  method  modulo  65536,  each  of  which  is  bounded  by  an  initial 
random  value.  Hence,  giving  an  initial  random  value  to  each  event  in¬ 
dependently,  the  simulation  is  able  to  have  reproductivity  of  the  sit¬ 
uations  except  the  events  depending  upon  trainee's  responses.  Conse¬ 
quently  effective  trainings/experiments  may  be  conducted  by  the  repe¬ 
tition  and  the  partial  modifications  of  situations  through  easy  speci¬ 
fications  of  distributions  and  their  initial  random  values. 

Generally  speaking  about  radar  simulators,  there  are  two  contrary 
requirements.  One  is  that  simulated  situations  must  be  produced  faith¬ 
fully  to  actual  traffic  flovs,  and  the  other  is  that  the  system  must 
be  able  to  produce  the  particular  situations  available  to  collision 
avoidance  trainings.  Answering  these  two  requirements,  two  types  of 
simulation  programs  are  proposed.  They  are  called  as  follows  for 
simplicity . 

Type  I  :  the  simulation  program  of  passing  through  a  channel,  and 

Type  H  :  the  simulation  program  of  collision  avoidance  trainings. 

Generation  of  Targets  on  Channel(Type  I) 

Considerings  the  generation  of  targets  passing  through  a  channel, 
the  time  intervals  of  ship’s  crossing  a  fixed  view  line  on  the  channel 
may  submit  to  the  exponential  distribution,  the  positions  passing  on 
the  line  may  follow  to  the  normal  distribution  and  the  ship  speeds  are 
assumed  to  obey  the  uniform  distribution.  The  simulation  of  a  mathe¬ 
matical  model  constructed  by  these  probabilistic  distributions  has 
reproductivity  because  the  generated  positions  of  targets  are  absolute 
and  the  other  events  are  independent  of  own  ship  movements.  However, 
it  is  difficult  to  realize  probabilistic  distributions  in  space  and 
time  domain  faithfully  according  to  arbitrary  given  parameters,  because 
a  channel  is  generally  crowded  traffic  area,  and  then  the  number  of 
ships  is  large  if  all  ones  on  the  channel  should  be  simulated.  Hence  it 
is  assumed  that  all  of  targets  pass  through  in  the  opposite  direction 
against  own  ship  in  order  to  realize  nearly  realistic  simulations  with¬ 
in  the  number  of  targets  limited  by  hardware  and  that  other  targets 
which  have  scarcely  effect  on  the  own  ship's  movements  are  not  display¬ 
ed  on  the  radar  indicator.  In  paticular  a  target  passed  through  the 
CPA(Closest  Point  of  Approach)  and  located  at  2  N.M.  in  the  rear  of 
own  ship  is  disappeared.  Then  it  is  utilized  for  the  next  coming 
target . 

Even  ii  such  procedure  is  performed,  the  numbers  of  targets  shown 
simultaneously  are  insufficient  for  the  specification  of  short  time 
interval.  As  the  simulator  offers  eight  targets  at  most,  the  queue  of 
targets  yields  a  gap  when  the  mean  value  of  time  intervals  of  targets' 
approach  is  less  than  about  3*5  minutes  although  it  depends  on  target's 
speed  and  other  factors.  This  figure  3*5  minutes  is  fairly  large  as 
compared  with  real  traffic  along  the  coast.  If  the  gap  can  be  ignored, 
it  is  possible  to  simulate  real  traffic  flows  partially.  This  problem 
needs  to  get  rid  of  hardware  restrictions. 

Input  parameters  for  the  distributions  are  shown  as  followings. 

1)  The  time  Intervals  of  targets  arrivals  to  the  entrance:  the  mean 
value  of  the  exponential  distribution, 

2)  the  mean  and  variance  of  target's  position  at  the  entrance  and  the 
exit  of  a  channel:  the  normal  distribution  as  the  width  of  channel, 
and 

3)  the  mean  and  variance  of  the  uniform  distribution  of  ship  speed. 
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The  initial  random  values  for  the  generation  of  distributions  are 
given  from  a  console.  As  to  2),  we  consider  that  the  distribution  of 
positions  passing  a  line  at  the  entrance  and  the  one  at  the  exit  are 
independent  and  each  target  proceeds  on  the  straight  line  connecting 
two  passing  points.  Therefore,  the  simulator  will  generate  the  situ¬ 
ation  that  each  target  goes  in  parallel  with  direction  of  a  channel  if 
the  same  initial  random  values  are  given  to  both  distributions  at  the 
entrance  and  the  exit.  The  type  I  program  does  not  simulate  altering 
course  and  speed  of  targets.  That  is  to  say,  as  passing  ships  in  a 
fairway  follow  the  same  direction  as  the  fairway  and  go  nearly  straight 
with  constant  speeds  generally,  the  simulation  of  altering  course  and 
speed  seems  to  be  non-realistic . 

Generation  of  Targets  in  Case  of  Collision  Avoidance (Type  H) 

This  type  does  not  neccessarily  simulate  realistic  traffic  flows 
because  its  main  purpose  is  trainings  of  collision  avoidance  maneuver¬ 
ing.  In  this  situation  own  ship  simulated  is  going  on  a  setting 
course  given  previously  and  at  the  same  time  targets  are  generated  to 
force  to  encounter  with  her  in  spite  of  the  present  course.  As  for 
the  target  generation,  the  probabilistic  factors  considered  here  are 
time  intervals  of  the  generation,  appearing  positions,  ship  speeds, 
degree  of  concentration  about  the  DCPA,  time  intervals  of  altering 
course,  and  angles  of  it.  Describing  the  probabilistic  factors  in 
detail,  following  distributions  are  assumed. 

1)  The  time  intervals  of  the  generation  are  based  on  the  time  to  be 
trapped  by  radar  and  are  considered  to  follow  the  Poisson  distribution. 

2)  The  positions  of  target's  appearances  are  determined  according  to 
the  normal  distribution  which  is  taken  on  a  circle  having  the  central 
point  on  the  own  ship. 

3)  The  ship  speed  is  the  uniform  distribution  as  same  as  type  I. 

4)  Each  target's  course  is  determined  such  that  she  collides  or  nearly 
collides  if  both  ships  keep  their  courses  and  speeds  because  encounter¬ 
ing  situations  must  occur  on  trainings  for  collision  avoidance  maneu¬ 
ver.  However  if  the  DCPA  of  the  own  ship  to  the  target  is  equal  to 
zero  at  the  begining  of  target's  appearance,  the  own  ship  always  comes 
into  collision  with  the  target.  Therefore,  the  target's  course  is 
given  such  that  the  DCPA  is  distributed  uniformly  within  the  specified 
width,  because  a  trainee  may  be  able  to  predict  the  target's  movement 
with  repetition  of  trainings  if  the  DCPA  is  always  equal  to  zero.  This 
means  that  even  if  a  trainee  should  leave  the  encounter  situation 

the  case  of  collision- free  may  occur  and  if  otherwise  the  own  ship  may 
collide.  Furthermore  this  may  make  difficulties  for  a  trainee  to  pre¬ 
dict  the  movements  of  targets  and  to  decide  the  suitable  maneuvering 
of  the  own  ship. 

5)  Each  ship  changes  its  course  and  speed  in  the  actual  sea  according 
to  the  intention  of  a  navigator  and  other  reasons.  Furthermore,  rules 
of  the  road  affect  the  managements  of  ship's  course  and  speed  according 
to  the  relations  of  the  obliged  vessels  and  the  burdened  vessels. 

Taking  into  consideration  of  these  factors  affecting  ship's  course  and 
speed,  it  is  difficult  to  design  a  computer  program  simulating  these 
situations.  On  the  other  hand  a  model  such  that  each  target  does  not 
change  its  course  and  speed  entirely  restricts  flexibility  of  traffic 
situations.  In  this  paper,  considering  that  the  altering  course  is  a 
usual  action  and  also  random  course  changings  in  some  degree  look  like 
effective  for  trainings,  it  is  assumed  that  the  time  intervals  of  al¬ 
tering  course  follow  tc  the  Poisson  distribution  and  the  angles  of 
those  follow  to  the  uniform  distribution  for  simplicity.  Concerning 
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the  altering  of  speed,  it  is  not  simulated  because  ships  hardly  alter 
their  speed  on  open  sea  except  for  urgent  cases. 

Note  that  parameters  of  1)  and  1)  are  dominant  factors  in  the 
situation  difficulty. 

APPLICATIONS  AND  EXAMPLES 

How  to  Utilize 

Applications  of  two  kinds  of  simulation  programs  are  shown  as 
follows . 

For  training  or  education--- 

Type  I  :  the  training  of  passing  through  a  narrow  channel. 

Type  E  :  the  training  of  collision  avoidance  including  the  ship 
maneuver  and  the  radar  plotting. 

For  analysis - 

Type  I  :  the  design  and  the  evaluation  of  channels,  for  example, 
the  assessment  of  accidents, 

Type  E  :  the  evaluation  of  the  criterion  for  collision  avoidance  etc.. 

Type  I  should  be  used  for  trainings  of  passing  through  a  narrow 
channel  includind  position  keeping.  On  training  of  collision  avoidance 
in  type  I,  though  it  is  possible  to  simulate  situations  encountering 
with  ships  in  opposite  direction,  the  own  ship  is  able  to  avoid  targets 
easily  and  this  is  not  suitable  for  the  standard  training  of  collision 
avoidance.  On  the  other  hand,  type  E  simulates  traffic  flows  in  open 
sea  and  possible  trainings  using  it  are 

1)  the  operation  of  radar  equipments  in  common  with  type  I, 

2)  the  exercise  of  radar  plotting, 

3)  the  collision  avoidance  maneuvering  including  1)  and  2),  and 

4)  the  composite  training  of  ship  handling  including  a  setting  to  a 
scheduled  route,  a  watch  work  and  so  forth. 

In  order  to  analyze  simulation  data,  it  is  required  to  gather  many 
kinds  of  trainings.  The  data  recorded  in  the  system  contain  various 
items  for  the  general  purpose.  The  examples  of  analysis  by  using  disk 
data  are 

1)  the  play  back  of  the  simulation  which  is  in  real  time  speed  or  in 
altering  speed, 

2)  the  marking  for  trainees, 

3)  the  evaluation  of  collision  avoidance, 

the  determination  of  the  criterion  for  collision  avoidance  (See  the 
next ) ,  and 

5)  the  design  and  the  evaluation  of  narrow  channels  on  type  I. 

The  Examples  of  the  Simulation 

Fig.  2  is  an  example  of  type  I.  Own  ship  keeps  her  course  as  0°. 

A  mark  for  identification  is  given  for  each  target  at  the  generation 
on  graphic  display. 

On  the  other  hand.  Fig.  3  is  tracking  data  of  type  E  ,  and  Fig.  4 
is  the  true  motion  diagram  corresponding  to  Fig.  3  made  from  disk  data, 
where  each  target  is  marked  every  five  minutes  by  delimiters.  In  this 
example,  the  trainee  is  informed  the  scheduled  course  (0°)  and  own 
ship’s  type  (the  bulk  carrier  of  2^0  meters  here),  and  he  is  instructed 
to  handle  only  by  the  radar  with  controls  of  a  steering  wheel  and  a 
main  engine.  The  function  c f  altering  course  is  suppressed  here. 
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Here,  we  show  an  analytic  example  which  propose  a  method  to  evalu¬ 
ate  the  criterion  for  a  collision  avoidance.  The  TCPA  and  the  DCPA  in 
disk  data  are  used.  Fig.  5  denotes  the  relation  that  a  value  of  the 
DCPA  at  A  is  equal  to  zero  and  then  a  collision  should  occur  if  this 
situation  goes  on  but  there  is  time  enough  to  avoid,  and  B  is  on  the 
DCPA  axis  but  there  is  a  room  in  distance.  If  own  ship  and  each  target 


keep  their  present  courses  and 
TCPA  axis  is  drawn  as  C .  If 
the  point  on  C  goes  on,  then 
the  line  passes  a  critical 
area.  Hence  when  ship  maneu¬ 
vering  is  ideal  in  a  sence, 
there  exists  an  inviolated 
area  like  a  hatching  section 
in  Fig.  5.  Fig.  6  shows  the 
relation  of  the  TCPA-DCPA 
corresponding  to  the  example 
of  Fig.  3.  In  this  example, 
the  trainee  keeps  the  DCPA  of 
about  1  N.M..  By  gathering 
examples  of  these  ideal  train¬ 
ings,  we  will  be  able  to  decide 
the  form  of  the  inviolated 
area.  This  might  make  a  good 
criterion  for  collision 
avoidance  maneuver. 


speeds,  then  a  parallel  line  with  the 


RADAR  SIMULATION 

Identifiers  of 
target  ships 


0' 

( — 


Channel  width: 

1.5  miles 

Mean  time  of  arrivals: 
5  minutes 

Mean  speed  of  targets: 
20  knots 


Figure  2.  An  Example  of  Type  I. 


Figure  3.  An  Example  of  Type  H  (Tracking  Data). 

C  2-8 


DCF' A  GRAPH  FOP  OlFA-TCPA 

(N  N  ) 

3  £1  DHTHAE 


2  el 


*■4 


A 


-1.3 

Figure  6.  A  Relation  of  the  TCPA-DCPA  for  the  Example  of  Figure3. 


SUMMARY 

This  radar  simulator  is  capable  of  the  trainings  of  passing 
through  a  narrow  channel  and  collision  avoidance,  and  of  the  analysis 
related  to  them  if  neccesary.  Especially  it  will  be  effective  in  the 
educational  usage. 

As  the  method  of  target’s  generation  is  probabilistically,  there 
exists  one  advantage  that  the  setting  situations  become  variously, 
but  how  to  decide  "good"  situations  is  a  remaining  problem.  Selection 
of  situations  has  serious  influence  on  the  effectiveness  of  trainings, 
and  therefore  data  of  various  trainings  must  be  saved  and  analyzed  in 
order  to  utilize  well.  It  is  of  interest  that  the  movements  of  targets 
are  affected  by  various  factors  besides  statistical  properties.  For 
example,  targets  including  own  ship  may  interfare  mutually  and  their 
movements  must  be  obeyed  under  some  rules.  This  simulator  has  a 
problem  that  Traffic  flows  on  narrow  channels  are  not  expressed 
throughly  on  account  of  hardware  restrictions.  Then,  one  solution  for 
this  problem  is  the  utilization  of  a  general  purpose  graphic  display 
with  the  dedicated  computer  to  control  it. 
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Figure  1  -  Ship  Propulsion  Mathematical  Model 


Diesel  Engine 

The  model  calculates  the  delivered  torque  as  a  function  of  speed  and  rack  posi¬ 
tion.  The  torque  is  taken  from  the  torque  map  delivered  by  the  engine  in  stationary 
conditions,  taking  into  account  the  engine  windmilling  conditions. 

Torque  rate  limiting  action  due  to  the  turbo-blower  dynamics  is  simulated  limiting 
the  actual  torque  rate  when  this  superates  a  threshold  function  of  the  previous  tor¬ 
que  value. 

Diesel  Engine  Speed  Governor 

The  model  of  the  diesel  engine  speed  governor  consists  in  a  subtraction  node 
between  the  set  and  present  speed;  the  output  of  the  node  modifies  the  position  of 
the  fuel  rack  with  a  proportional  and  integrative  action.  The  maximum  rack  position 
is  limited  according  to  the  actual  speed  set.  The  speed  set  varies*  according  to  the 
control  schedule,  with  a  constant  rate  to  simulate  the  dynamics  of  the  speed  sexting 
motor. 

Gas  Turbine 

The  model  calculates  the  delivered  torque  as  a  function  of  throttle  position 
and  turbine  speed.  The  torque  is  calculated  as  a  function  of  the  fuel  consumption 
and  turbine  speed,  extrapolated  for  the  values  of  negative  torque  (turbine  at  idle 
in  windmilling  condition).  Between  the  throttle  fuel  function  and  the  torque/speed/ 
fuel  map  a  time  constant  function  of  the  fuel  consumption  is  provided  in  order  to 
simulate  the  time  lag  introduced  by  the  speed  governor  of  the  gas  generator. 

The  throttle  position  rate  is  limited  in  order  to  simulate  the  behaviour  of  the  tur¬ 
bine  power  lever  actuator  electronics. 
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Reduction  gear 

The  reduction  gear  is  considered  as  an  ideal  mechanical  energy  transformer  ac¬ 
cording  to  the  following  relations: 

N1'N2  primary/secondary  speed 

(1)  ^  -  r  $1*92  primary /secondary  torque 

(?2  r  reduction  ratio 

The  reduction  gear  friction  losses  are  taken  into  account  together  with  the  losses 
due  to  shaft  driven  pumps  as  a  function  0R  =  QR  (N)  of  the  shaft  speed. 

Propeller  pitch  operation 

Propeller  pitch  actuation  rate  is  function  of  the  delivery  of  the  pumps. 

The  shaft  driven  pump  delivery  is  function  of  the  shaft  speed,  whilst  the  delivery 
of  the  motor  driven  pump  is  considered  constant. 

In  the  simulation,  the  influence  of  the  oil  pressure  on  the  pump  delivery  has  not 
been  considered. 

Propeller 

To  calculate  the  propeller  torque  and  thrust  the  following  formulas  are  used: 

(2)  Qg  s  O  .  bre  .  KQ.D  . propeller  torque 

(3)  T£  =  ^  .  btd  .  KT.D4.N2  propeller  thrust 

KQ  and  KT  are  respectively  the  coefficients  of  the  torque  and  thrust  of  the  isolated 
propeller.  These  coefficients  are  function  of  the  propeller  pith  and  the  advance 
coefficient  J. 

The  meaning  of  the  remaining  symbols  is  as  follows: 

D:  propeller  diameter  N:  shaft  speed 

sea  water  specific  mass  V:  ship  speed 
The  advance  coefficient  is  defined  by  the  following  formula: 

(4)  J  =  ( V .  bwf )  /  ( N .  D } 

As  the  reversal  of  the  ship's  motion  is  obtained  through  the  propeller  pith  change, 
the  shaft  speed  is  kept  higher  than  a  minimum  value  and  the  coefficient  J  value  is 
always  between  the  limits  -  1,4  +  1,4. 

The  coefficients  bre,  bwf  and  btd  (hydrodynamic  coefficients  normally  function  of 
the  speed  V),  modify  the  propeller  equations  for  the  hull  influence  as  follows: 

bre  -  Torque  Coefficient  -  The  torque  coefficient  takes  into  account  the  proxi¬ 
mity  of  the  propeller  to  the  hull  which  increases  the  propeller  friction  in  the  water; 
therefore  the  torque  absorbed  by  the  propeller  in  its  true  installation  is  greater 
than  that  absorbed  by  the  isolated  propeller. 

btd  -  Thrust  Coefficient  -  The  thrust  coefficient  takes  into  account 
that  the  propeller  when  rotating  attracts  the  water  in  the  space  which  separates 
the  propeller  from  hull  and  push  it  astern.  The  water  flow  near  the  hull 

increases  its  resistance  to  the  motion  in  relation  to  the  resistance 

presented  in  towing  conditions.  The  increase  in  resistance  due  to  this  effect  is 
considered  as  a  reduction  of  the  propeller  thrust. 
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bwf  -  Wake  Coefficient  -  The  wake  coefficient  takes  into  account  that 
the  water  in  which  the  propeller  rotates  is  not  stationary  but  is  dragged  into  mo¬ 
tion  by  the  hull  itself ;  the  propeller  has  to  move  in  the  water  with  a  lower  advance 
speed  than  that  of  the  ship. 

Hull  Resistance 

The  function  of  resistance  to  the  ship's  motion  both  for  ahead  and  astern  mo¬ 
tion  ,  is  obtained  from  the  tank  tests  of  the  ship  model. 

Total  Mass  Of  The  Ship 

The  total  mass  of  the  ship  is  considered  to  be  the  mass  of  the  ship  plus  an 
estimated  term, function  of  the  water  mass  driven  into  motion  by  the  hull. 

Control  System 

The  control  system,  acts  on  the  propeller  pitch  demand  and  the  gas  turbine 
throttle  demand  or  the  diesel  speed  demand, { according  to  the  type  of  machine  in  pro¬ 
pulsion)  according  to  the  position  of  a  ship  speed  control  lever, taking  into  account 
actual  values  of  propeller  pitch  and  speed. 

As  the  control  system  operates  through  a  process  computer,  there  is  no  difference 
between  the  control  algorithms  relevant  to  the  control  system  and  those  used  in  the 
simulation. 

Torque  and  Thrust  Balance  Equations 

The  models  described  previously  are  linked  together  by  the  following  differen¬ 
tial  equations: 


(5) 

Qm  -  Qf  -  Qb  = 

dN 

torque 

equation 

2  TT 

dt 

(6) 

dV 

n.Tp  -  R  =  M  . 

thrust 

equation 

dt 


The  following  definitions  apply: 
n  =  number  of  shafts  in  propulsion  (one  or  two) 

Qm  motrix  torque 

I  moment  of  inertia  of  the  rotating  masses 
R  hull  resistance  to  motion 
M  total  mass  of  the  ship. 

Further  Models  Details 

Model  design  has  been  developed  first  to  achieve  an  optimal  control  system  and  se¬ 
condary  to  foresee  ship  performance  response. 

One  of  the  aims  of  the  control  system  is  to  allow  fast  and  safe  propulsion  plant 
operation  in  every  operating  condition.  The  variations  in  operating  conditions  are 
due  to  variations  of  displacement,  hull  fouling,  engines  wearing.  These  variations 
permit  not  to  take  into  account  parameters  which  present  lower  changes. 
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For  example  the  hydrodynamic  coefficients  of  the  propeller  have  been  kept  constant 
to  the  average  value  (considering  also  that  they  have  difficult  measurements  and 
there  are  difficulties  in  verifying  them  during  the  sea  trials  of  the  ship). 

Simulation  Implementation 

The  simulation  has  been  carried  out  on  a  minicomputer  programming  in 
Basic  and  Assembler  languages.  The  algorithms  relative  to  the  machinery  and  the  ship 
are  written  in  Assembler,  whfst  the  algorithms  of  the  control  system  and  the  running 
structure  of  the  program  and  the  print  subroutines  are  in  Basic;  this  choice  was  done 
to  permit  easy  modifications  of  the  control  system  algoritms  whilst  retaining  hight 
computation  speed  of  the  machinery  algorithms. 

The  calculation  of  the  integrals  has  been  made  with  the  rectangles  formula. 

The  sampling  period  has  been  chosen  in  function  of  the  speed  rate  of  the  variables; 
it  is  0.2  seconds  for  the  algorithms  involved  in  the  torque  equation  and  0,5  seconds 
for  those  involved  in  the  thrust  equation  and  in  the  model  of  the  pitch  actuator. 

SIMULATOR  FOR  PROPULSION  CONTROL  SYSTEM  TESTING 

The  automatic  control  system  is  computer  based.  It  provides  the  automatic  con 
trol  of  the  propulsion  machinery,  and  the  automatic  starting/stopping  both  for  the 
diesel  and  gas  turbine  engines.  The  control  system  also  carries  out  change-over  se¬ 
quences  in  a  fully  automatic  mode.  During  such  sequences  the  manual  controls  are 
still  operative, in  order  to  allow  the  operator  to  interrupt  an  automatic  sequence 
and  keep  on  doing  it  manually.  All  that  is  done  by  a  control  system  which  is  forced 
to  consider  the  greatest  number  of  possible  propulsion  system  conf igurations  (false 
indication  caused  by  sensor  failures  are  considered  also). 

In  ordrr  to  test  the  control  system  completely  and  truly  before  carrying  out 
the  sea  trials,  a  simulator  of  the  machinery  of  one  of  the  ship's  shafts  (the  two 
shafts  are  the  same  and  independent  from  each  other)  has  been  designed. 

The  simulator  receives  the  commands  from  the  automation  plant  under  test  and  provides 
feedback  signals  which  represent  the  functioning  conditions  of  the  machinery  elabo¬ 
rated  with  the  same  dynamics  as  the  actual  machinery. 

Starting  and  Stopping  of  the  Diesel  Engine 

The  model  calculates  the  torque  delivered  by  the  engine  during  the  start  phase  and 
the  conditions  which  cause  the  change-over  from  engine  not  running  to  engine  running 
models.  Engine  running  conditions  are  those  taken  into  account  in  the  control  system 
design.  The  engine  not  running  consists  in  the  delivery  of  a  constant  negative  torque. 
The  model  of  the  engine  running  calculates  the  torque  delivered  by  the  starting 
air  actioning  the  cylinders.  The  torque  is  function  of  the  speed  and 

the  air  pressure.  The  engine  is  considered  running  when,  with  fuel-on  condition 
it  reaches  the  idle  speed. 

Starting  and  Stopping  of  Gas  Turbine 

The  starting  model  of  the  turbine  calculates  the  speed  of  the  gas  generator  and 
the  temperature  of  the  power  turbine  inlet  gas  as  a  function  of  present  speed,  with 
starter,  igniters  and  fuel  controls  in  "on*'  condition. 

The  turbine  is  considered  as  running  when  the  gas  generator  speed  reaches  the  ’’flame 
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on"  speed  with  igniter  and  fuel  on  {combustion  without  self-sustainment)  or  when 
the  speed  of  the  gas  generator  reaches  the  idle  value. 

When  the  turbine  is  running,  the  model  developed  for  the  design  of  the  control 
system  is  turned  on;  otherwise  the  stopped  engine  model,  which  foresee  a  negative 
torque  speed  function,  is  turned  on. 

Friction  Clutch 


The  condition  of  the  friction  clutch  influences  the  differential  equation  used 
for  the  speed  calculation.  In  the  friction  clutch  engaged  condition,  equation  (7) 
is  used. 


(7)  <?D  +  <Qt)  -  Qe  =  IA+In+(lT)  *  dNA  ;  ND  -  NA 

2  TT  dt 

The  magnitudes  influenced  by  the  state  of  the  synchronizing  clutch  are  indicated 
in  brackets. 

With  the  friction  clutch  open  or  slipping.the  equation  (7)  transforms  into  equation 

(8) . 


(8) 

In 

V-Of  -  • 

2  TT 

dNn  I, 

D  ;  Of-Op  =  A 

dNA 

dt  2  TT 

dt 

Where : 

nd 

diesel  speed 

Qd 

diesel  torque 

na 

shaft  speed 

Of 

slipping  clutch  torque 

Id 

diesel  engine 

moment  of  inertia 

Qe 

propeller  torque 

XA 

shaft  moment 

of  inertia 

The  torque  Qp  is  the  torque  through  the  clutch;  the  module  of  Qp  is  function  of  air 
pressure  P  {the  clutch  is  air  operated);  the  sign  of  Qp  is  that  of  the  difference 
nD  “  NA»  considering  NA  the  speed  of  the  output  shaft  of  the  clutch. 

Pressure  P,  when  the  clutch  closure  is  commanded,  increases  according  with  a  sche¬ 
dule  .until  it  reaches  the  stationary  "on"  value. 

When, with  pressurized  clutch, it  is  verified  that  Nq  =  N^,  instead  of  equation  (8), 
equation  (7)  is  used.  When  0D  >  Of  (assuming  that  the  inertia  of  the  diesel  engine 
in  far  lower  them  that  of  the  reduction  gear)  the  clutch  begins  to  slip  and  instead 
of  equation  (7)  equation  (8)  is  used. 

Synchronizing  Clutch 


In  the  synchronizing  clutch  disengaged  condition  the  turbine  is  independent  from 
the  shaft;  the  differential  equation  which  calculates  the  speed  is  the  following: 


(9)  Qt  = 


2  TT 


I-p  turbine  inertia 

(?T  turbine  torque 

Nj  turbine  speed 


When  the  clutch  is  engaged, the  speed  of  the  turbine,  egual  to  the  shaft  speed,  is 
calculated  with  the  following  formula: 


(10)  Qt  +  (Qd,  qf)  -  Qe 


do) 


dNA 


2  IT 
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The  magnitudes  influenced  by  the  state  of  the  friction  clutch  are  indicated  in 
brackets. 

The  model  of  the  clutch  passes  from  the  disengaged  condition  to  the  engaged  condi¬ 
tion  when,  having  the  clutch  been  preset  to  engagement,  the  speed  of  the  turbine 
tends  to  be  greater  than  the  output  shaft  speed  connected  with  the  reduction  gear  . 
The  clutch  changes  from  the  engaged  condition  to  the  disengagement  when,  as  the 
disengagement  is  pre-set,  the  turbine  torque  Q*j  becomes  negative. 

Propeller 

The  equations  used  into  the  control  system  design  are  for  shaft  speeds  over  a 
certain  value.  For  lower  shaft  speeds  the  advance  coefficient  J,  computed  by  means 
of  the  equation  {4)  reaches  highter  values  outside  the  range  of  tabulation  of  the 
coefficients  KQ  and  KT. 

To  simulate  the  behaviour  of  the  propeller  also  for  low  or  null  shaft  speeds  'he 
following  equations  have  been  used: 

rt  2  2 

(11)  y  .bre.K'Q.D-3.  (  (V.bwf)  +{N.D)  )  propeller  torque 

(12)  y .btd.K'T.D2.  (  (V.bwf)2+(N.D)2  )  propeller  thrust 

K'Q  and  K'T  are  modified  coefficients  of  torque  and  propeller  thrust. 

These  coefficients  are  function  of  the  propeller  pitch  and  of  the  modified  advance 
coefficient  J.  The  relations  between  the  modified  coefficient  and  normal  ones  are 
as  follows. 

(13)  K'Q  -  KQ  ;  k'T  *  KT  ;  J'  = 

Simulator  Description 

The  simulator  has  been  based  on  a  16  bit  word  minicomputer  connected  to  an  ana¬ 
log  and  digital  input/output  interface  to/from  the  automation  plant  under  test. 

The  software  of  the  minicomputer  consists  in  a  simulation  program  managed  by  a 
~eal  time  operative  system.  The  simulation  programme  is  divided  into  a  start  modulus 
*.lso  controlling  a  CRT  terminal,  in  the  fast  calculation  and  in  the  slow  calcula¬ 
tion  moduli.  The  start  modulus  is  started  up  by  the  operative  system  at  computer 

power  on  time . 

The  start  modulus  first  qualifies  the  execution  of  the  other  moduli, then  keeps 
turning  in  loop,  controlling  the  display  terminal.  Through  the  CRT  terminal  it 

is  possible  to  modify  on-line  the  model  parameters  and  read  the  values  of  the  simu¬ 
lated  variables. 

The  fast  calculations  modulus  is  periodical  and  is  carried  out  by  the  operative 
system  every  0.2  seconds.  The  module  obtains  input  values  from  the  automation 

plant  (e.g.:  the  value  of  the  gas  turbine  throttle  or  the  condition  of  the  friction 
clutch  engagement  command),  carries  out  the  algorithms  relative  to  the  balancing 
equation  of  the  torque  and  transmits  the  results  to  the  automation  plant  (e.g.:  the 
value  of  the  actual  propeller  shaft  speed). 

The  slow  calculation  modulus  is  similar  to  the  fast  calculation  module  but  has 
a  periodicity  of  0.5  seconds.  The  slow  calculation  module  executes  the  algorithms 
of  the  models  whose  variables  do  not  vary  very  quickly  and  can  therefore  be  calcu¬ 
lated  with  a  relatively  slower  sampling  period. 

All  the  programmes  are  written  in  Assembler,  the  mathematical  calculations  are 
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carried  out  with  notation  in  fixed  point  to  get  calculation  speed  higher  than  that 
of  a  programme  with  calculations  in  floating  point.  The  use  of  the  notation  in 
fixed  point  has  called  for  the  conversion  of  all  the  variables  in  a  numerical  scale 
defined  between  the  limits  of  -3276?  and  +32767.  The  use  of  the  fixed  point  needs 
precautions  in  the  execution  of  the  calculations  due  to  overflow  and  rounding  off 
problems. 

SIMULATOR  FOR  A  TRAINER 

In  the  following  paragraphs  details  are  supplied  on  a  trainer  for  CODOG 
frigate  propulsion  control  system  operators.  The  trainer  is  partitioned  into  two 
sections:  a  propulsion  control  console  (quite  the  same  as  that  fitted  on  board)  and 
a  simulator  console. 

A  prospective  view  of  the  propulsion  plant  and  of  the  control  system  is  shown  in 
Figure  2. 

Figure  3  is  a  photograph  of  a  trainer  realized  for  the  Italian  Navy. 

The  trainee  actions  the  controls  of  the  automatic  control  console  according  to 
the  instructor's  orders.  The  simulator  reproduces  exactly  and  in  real-time  the 
behaviour  of  the  propulsion  machinery  and  the  hull,  it  is  therefore  able  to  stress 
the  control  system  (and  the  trainee)  so  as  to  reproduce  the  on  board  operation  in  a 
completely  realistic  manner. 

During  the  training  periods  the  instructor  is  at  the  command  console  of  the  simula¬ 
tor.  He  carries  out  the  actions  to  the  trainees  as  working  from  the  ship's  bridge: 
in  fact  the  instructor  is  able  to  transmit  speed  and  course  orders  be  means  of  a 
couple  of  telegraphs  (the  same  are  fitted  on  board  on  the  bridge).  The  instructor  is 
acknoledged  about  the  machinery  through  a  duplicate  of  the  main  indicators  fitted  on 
the  control  room  console.  The  instructor  can  read  on  a  CRT  terminal  the  parameters 
representing  the  behaviour  of  the  ship  which  are  not  available  on  the  actual  ship, 
(e.g,:  the  value  of  the  propeller  thrust). 

The  instructor  can  influence  the  functioning  of  the  simulated  machinery  by  modifying, 
through  the  CRT  terminal,  the  functional  parameters  of  the  models  (such  as  the  ef¬ 
ficiency  relating  to  the  machinery,  the  displacement  of  the  ships  the  sea  motion). 
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Figure  2  -  Automation  plant  and  ship's  propelling  machinery 
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Figure  3  -  Ship  propulsion  trainer 

The  instructor  can  introduce  misfunctions  on  the  models  either  by  action  on 
the  CRT  keyboard  or  by  means  of  indipendent  switches.  The  introduction  of  misfunctions 
is  particularly  useful* because  it  allows  the  operators  to  recognize  the  abnormal 
situation  in  the  propelling  machinery  through  actions  and  indications  given  by  the 
control  system  and  to  learn  how  to  carry  out  the  appropriate  action. 

The  simulator  allows  the  contemporary  simulation  of  the  two  ship’s  shafts 
functioning  assimmetrically  and  of  their  reciprocal  interactions. 

The  machinery  simulator  uses  the  models  developed  for  the  control  system  testing, 
integrated  with  models  previously  omitted  because  they  did  not  influence  control 
system  action  or  did  it  with  constant  logical  conditions.  A  brief  description  of 
the  further  models  added  follows. 

Model  Of  The  Reduction  Gear  Lubrication  And  Cooling  System 

The  model  calculates  pressure  and  temperature  of  the  lubricating  oil  and  cooling 
water  of  the  reduction  gear.  The  pressures  are  function  of  the  shaft  speed  and  of  oil 
temperature  and  are  enabled  according  with  run/stop  condition  of  electropumps. 

The  temperatures  are  function  of  the  power  transmi tted  by  the  reduction  gear  and  of 
the  pressure  of  the  fluids.  The  functions  and  the  time  constants  which  simulate  the 
dynamics  of  the  system  in  normal  conditions  have  been  obtained  from  registrations 
carried  out  on  board  on  similar  systems,  in  operating  conditions.  The  function 
concerning  anomalous  functioning  conditions  has  been  extrapolated  from  those 

referring  to  normal  conditions. 

The  instructor,  through  commands  at  the  simulator,  can  select  a  normal  or  abnor¬ 
mal  functioning  to  train  the  crew  to  act  in  the  presence  of  misfunctioning . 

Signals  driving  indicators  or  fed  intc  the  alarm  and  monitoring  system  rela¬ 
ting  to  the  cooling  and  lubrication  of  the  engines,  bearings  and  propeller  pitch 
servo  have  been  calculated  in  a  similar  way. 

Modifications  To  The  Computation  Of  The  Propeller  Torques  And  The  Equation  Of  The 
Thrust  To  Take  Into  Account  The  Interaction  Between  The  Shafts 

The  propeller  torque  QE  of  each  shaft  is  multiplied  by  a  coefficient  normally 
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unitary,  function  of  the  sum  of  two  terms;  the  first  is  a  periodical  term  simulating 
the  sea  motion,  the  second  simulates  the  effect  of  the  rudder  and  is  function  of 
the  product  of  the  ship  speed  and  the  rudder  angle. 

The  thrust  equation  previously  described  is  modified  to  take  into  account  the  influen¬ 
ce  of  the  two  propeller  shafts  as  follows: 

right  propeller  thrust 
left  propeller  thrust 

Air  Starting  System  Model 

The  air  starting  system  consists  in  a  series  of  compressors,  tanks  and  pressu¬ 
re  reductors  which  supply  compressed  air  for  various  systems  and  for  the  starting 
of  the  diesel  and  turbine  engines.  The  models  calculates  the  air  pressure  in  the 
tanks.  The  pressure  increases  according  to  the  actioning  of  the  motor  driven  compres¬ 
sors  and  decreases  when  the  engine  starter  air-valves  are  opened. 

Simulation  Of  The  Sensors  And  Actuators 

In  the  training  unit  the  simulator  is  connected  to  the  automation  plant  so  as 
to  also  simulate  the  electrical  behaviour  of  the  sensors  and  actuators  fitted  on 
the  machinery. 

This  feature  has  brought  the  development  of  interface  electronics  simula¬ 

ting  the  electrical  behaviour  of  thermoresistors,  thermocouples,  differential 
transformers,  potentiometers  and  servovalve  coils. 

Trainer  Lay-Out 

The  trainer  system  overall  lay-out  is  shown  in  Figure  4. 

The  automation  plant  consists  in  a  propulsion  control  system  and  a  monitoring  sistem. 

The  control  system  is  based  on  two  modules  including  a  minicomputer  and  its 
relevant  in/out  electronics.  The  two  interfaces  units  (one  per  shaft) are  independent. 

Cne  computer  controls  both  the  shafts,  the  other  acts  as  a  back-up  to  the  first. 
The  "master"  computer  supplies  to  the  "slave"  the  results  of  the  elaboration. 

If  the  master  computer  breaks  down,  a  watchdog  feature  turns  the  slave  computer  into 
action.  The  slave  computer,  having  been  continuosly  up-dated,  is  able  to  keep  control 
in  a  smooth  and  bumpless  way  as  far  as  control  system  and  propulsion  plant  are 
concerned. 

The  monitoring  system  is  based  on  a  computer-based  module  which  manages  200 
channels  supplied  by  six  data  conditioning  terminals. 

The  data  conditioning  terminals  fitted  in  the  engine  room,  receive  signals  from  the 
sensors,  normalize  the  scale,  convert  them  into  digital  signals  and  transmit  them 
through  serial  lines  to  the  computer  module. 

This  system  allows  a  considerable  reduction  in  the  number  of  connection  cables 
between  the  engine  room  and  the  control  room. 

The  simulator  consists  in  three  interconnected  computer  based  modules. 

Two  modules  are  connected  together  by  the  third  through  a  serial  line. 

The  two  side  modules  each  simulates  the  machinery  of  a  shaft  of  the  ship. 

The  central  module  simulates  the  models  common  to  the  two  shafts  such  as  the  hull, 
the  sea  motion,  and  the  common  auxiliary  machinery. 
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PROPULSION  PLANT  CONTROL  AND  MONITORING  SYSTEM 


PROPULSION  PLANT  AUTOMATIC  CONTROL  UNITS  MONITORING  AND  ALARM  UNIT 


FIG. 4  TRAINER  SYSTEM  LAY-OUT 


DL  1-11 


The  central  module  drives  the  CflT  terminal  for  communication  with  the  instructor;  it 
also  emulates  the  six  data  conditioning  terminals  and  it  is  connected  with  the  moni¬ 
toring  system  through  six  serial  lines. 

The  basic  structure  of  the  three  modules  of  the  automation  plant  and  the  three  modu¬ 
les  of  the  simulator  is  the  same. 

Oneof  the  modules  is  shown  in  Figure  5. 


Figure  5  -  Interface  and  Computer  Module 


the  facility  were  discussed  in  Ref  (1).  This  paper  presents  the  work  to  date  on 
achieving  those  aims  by  outlining  the  mechanics  of  the  system  produced  and 
discussing  the  problems  encountered. 

THE  EVALUATION  CENTRE 

Various  possible  options  were  considered  for  providing  the  evaluation  faciity. 
These  ranged  from  testing  against  the  actual  plant  on  a  test  bed  to  the  use  of 
different  forms  of  simulation  and  these  are  discussed  in  Ref(l).  The  use  of  digital 
computer  based  simulations  however  provides  a  cost  effective  and  flexible  means  of 
meeting  the  evaluation  requirements.  Flexible  because  functions  may  be  added  or 
plant  characteristics  changed  by  rewriting  software. 

The  Evaluation  Centre  currently  incorporates  six  mini  computers  which  simulate 
a  COGAG  propulsion  system.  The  computers  are  configured  as  shown  in  Fig  1  with 
four  mini  computers  containing  simulations  of  the  major  items  of  plant,  gas 
turbines,  gearbox,  and  controllable  pitch  propeller,  with  a  fifth  representing  the 
propeller  load  and  hull  resistance.  These  five  minis  are  connected  via  16  bit 
parallel  data  links  to  a  central  master  computer  which  controls  the  running  of  the 
individual  simulations,  co-ordinates  communication  between  them  and  simulates  the 
interaction  between,  the  various  propulsion  elements  by  solving  the  system  level 
equations.  This  master  computer  also  acts  as  a  central  data  collection  point  and 
provides  a  number  of  operator  facilities  for  data  display  and  storage. 

A  number  of  different  options  were  considered  when  deciding  how  the 
simulations  and  their  computers  should  be  configured  and  these  are  discussed  in 
Ref (2).  The  chosen  c ^figuration  has  the  following  advantages: 

i.  Each  simulation  is  contained  within  an  individual  computer;  it  is  the 

requirements  of  each  individual  simulation  that  dictate  the  size  and  power 
of  each  computer;  if  the  requirements  of  a  particular  simulation  change 
and  the  chosen  processor  is  too  small  then  that  processor  can  be  upgraded 
without  affecting  the  rest  of  the  system. 

ii.  If  additional  plants  are  considered  necessary  these  can  be  simulated  in  a 
separate  computer  and  linked  into  the  master  via  an  additional  parallel 
link. 

iii.  The  central  computer  acts  as  a  control  station  controlling  and 
synchronizing  the  operation  of  the  simulation  computers. 

iv.  By  selecting  a  fairly  large  and  powerful  mini  for  the  central  computer  a 
range  of  operator  facilities  can  be  supplied  including  data  collection  and 
display. 

Each  mini  has  associated  with  it  a  number  of  interface  devices  which  allow 
the  simulation  to  communicate  with  the  master  computer  and  with  its  respective 
control  unit.  The  control  unit  interfaces  convert  the  simulation  generated  signals 
into  a  form  that  the  controllers  would  normally  expect  to  receive  via  plant  mounted 
transducers, and  conditions  the  controller  output  signals  to  suitable  levels  for  use 
by  the  simulation  computers. 

Real  time  operation  of  the  simulations,  essential  for  testing  prototype 
control  equipment,  is  governed  by  a  master  clock  within  the  central  computer.  At 
the  beginning  of  each  time  step  the  central  computer  issues  a  directive  to  start 
the  operation  of  the  individual  simulations.  On  receipt  of  this  directive  each 
simulation  updates  the  control  system  interfaces  with  data  calculated  during  the 
previous  time  step,  reads  in  demands  issued  by  the  controller  and  then  executes 
its  simulation.  On  completion  data  is  transmitted  to  the  master  computer  and  the 
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simulation  computer  lies  dormant  for  a  period  of  tiro. 

Once  all  the  simulations  h  ve  completed  the  communicar.  i  i.  to  the  master 
comruter,  the  system  level  equations  are  then  calculated  and  the  results  sent  to 
the  simulations  for  use  during  the  next  time  step.  All  these  activities  have  to 
be  completed  inside  the  system  tine  step  or  real  time  operation  cannot  be 
maintained.  Fir  2  shows  the  series  of  events  and  timing  of  these  various 
activities  for  the  propulsion  system. 

Thu  KdU'JLoIC:. 

The  facility  is  being  applied,  initially,  to  the  evaluation  of  a  digital 
control  system  for  a  warship  propulsion  plant.  The  propulsion  plant,  for  which  the 
control  system  has  been  designed,  is  a  CCCAi  configuration  and,  because  it  has 
been  designed  without  a  specific  ship  in  mind,  has  been  termed  the  ’deference 
System.  As  shown  in  Fig  3»  two  Rolls-Royce  SK1A  gas  turbines  drive  into  a 
combining  -ear box  which  contains  primary  and  secondary  gearing,  self  selecting 
clutches  on  each  intermediate  shaft,  a  disc  brake  att  '-hed  to  the  output  half  of 
one  of  the  intermediate  shafts  and  a  slow  speed  shaft  turning  motor.  The 
controllable  pitch  propeller  system  is  based  on  the  otone  Fangnre.se  ;rine 
Engineering  Ltd  open  circuit  hydraulic  system.  In  order  to  provide  a  representative 
load  for  the  system  nominal  ship  resistance  and  propeller  toroue/tsrurt 
characteristics  hr ve  been  defined  for  a  shir  of  5000  tonnes  displacement . 

The  roisuij « ients  of  the  simulations  can  be  considered  on  two  levels.  At  the 
system  level  they  provide  a  dynamic  simulation  of  th-  complete  propulsion  system. 

At  this  loveL,  considerar  ion  cf  the  system  dynamics  deter  ines  the  overall  system 
tine  stop  an:  dictates  the  minimum  number  of  inter  simulation  parameters  rf  ;;uet! 
to  model  tne  complete  system. 

Cn  the  second  1  vel  the  individual  plant  simulations  are  retired  to  respond 
to  all  the  demands  issued  by  the  control  units  and  to  supply  all  the  signals 
normally  transduced  on  the  l  «al  plant.  These  simulations  have  to  be  fully  dynamic 
and  have  to  be  capable  of  representing  the  plant  in  all  its  possible  operating 
states,  namely  from  being  deed  with  «  veryt  ing  switched  off  to  running  in  excess 
of  full  power.  «t  this  level  the  nu~b._*r  ol  functions  required  by  th-  control  unit, 
toyetner  with  the  complexity  of  the  riant,  determines  the  complexity  and  hence 
size  of  the  simulation.  If  the  plant  lyna-.ics  cannot  be  accurately  me  ie lied  using 
the  overall  syrtem  time  step  then  the  individual  Simula!  ion  tine-rters  have  to  be 
set  to  apt ropriate  factors  of  the  syrtem  time  step. 

In  the  case  of  the  propulsion  system  simulation  the  overall  time  cter  was  set 
at  120  milli-seconda  while  the  gas  turbine  and  contm-llai  le  pitch  jrop-eller  run 
with  ms  time  steps. 

ga..  tvrpi::=: 


As  can  be  s-er.  in  Fig  *+,  ir.  ‘  erms  of  the  propulsion  syste-  the  rar  turbine 
simulations  are  rf  -lired  to  convert  ir.tut  fuel  flow  into  torque  developed  by  the 
po*.-er  turbines.  In  terms  of  th°  control  unit  requirements  they  have  to  re  -.pond  to 
some  12  discrete  icruts  ana  su:  ply  It"  stat  e  indications  with  >0  analogue  outputs. 

Of  these  analogue  outruts  six  are  u«ed  a*  feedback  signals  for  a  cent  mu.  is  analogue 
controller,  as  described  in  Ref  .1)  for  control  1 ing  Lr  spool  speed  an:  for  ensuring 
that  the  engine  dees  not  enter  any  ur.lesiraMe  orer  ting  retires,  the  rr-nini?r  are 
used  for  surveillance  rur; oses. 
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The  simulation  models  both  the  gas  generator  and  the  power  turbine 
characteristics,  also  the  on-engine  fuel  controls,  as  shown  in  Fig  5*  and 
includes  ancillary  functions  for  producing  lub  oil  pressures  and  temperatures  etc. 

For  the  purposes  of  producing  the  simulation  the  engine  operating  range  was 
considered  to  consist  of  two  stages,  dead  to  idle  and  idle  to  full  power.  The 
region  from  dead  to  idle  has  been  modelled  using  look  up  scenarios  which  output 
parameters  during  the  start  up  and  shut  down  phases  as  a  function  of  time  and  in 
response  to  the  control  system  demands.  A  transfer  function  type  approach  has 
been  adopted  to  model  the  region  between  idle  and  full  power.  The  simulation  is 
based  on  a  form  developed  by  Rolls-Royce  and  uses  a  combination  of  measured  data 
and  derived  functions  to  predict  the  steady  state  and  transient  operation  of  the 
engine.  A  block  diagram  of  the  model  structure  is  shown  in  Fig  6.  The  advantages 
of  this  form  of  model  are  that  it  is  extremely  straightforward  to  implement, 
requires  very  little  computing  time  and  power,  and  can  be  updated  by  simply 
replacing  data  tables.  The  disadvantages  are  that  only  a  limited  number  of 
parameters  are  actually  developed  as  part  of  the  modelling  process  but  for  control 
systems  evaluation  purposes, the  model  can  be  structured  so  as  to  produce  those 
required. 

In  order  to  model  the  gas  turbine  dynamics  accurately*  and  ensure  stable 
operation  when  run  in  conjunction  with  the  closed  loop  controller,  the  simulation 
time  step  had  to  be  reduced  to  40  ms.  This  means  that  the  gas  turbine  simulation 
has  to  complete  three  cycles  and  communicate  to  the  control  unit  three  times 
during  the  120  ms  system  time  step;  communication  to  the  central  computer  still 
only  occurs  every  120  ms. 

GEARBOX 

In  order  to  maintain  synchronous  operation  of  the  complete  system  the 
functions  of  the  gearbox  have  to  be  split  such  that  the  gearbox  simulation 
only  determines  the  system  configuration,  by  determining  the  clutch  states,  while 
the  torque  balance  system  level  calculations  are  performed  in  the  central  master 
computer. 

Inputs  to  the  system  level  equations  are  the  two  power  turbine  torques  and 
the  propeller  shaft  torque  together  with  the  gearbox  clutch  states.  The  shaft 
equations  combine  these  torques  according  to  the  engine/clutch  configuration  and, 
allowing  for  losses,  produce  new  estimates  of  shaft  acceleration  and  hence  speeds. 
These  updated  shaft  speeds  are  returned  to  their  respective  simulations  for  use 
during  the  next  time  step.  The  gearbox  simulation  itself  contains  mathematical 
representations  of  the  self-selecting  clutches,  shaft  brake  and  turning  motor. 

The  clutches  are  of  the  SSS  Ltd  non  baulking  type  and  the  simulation  models 
the  action  of  ratchet  and  pawl  mechanisms,  the  sliding  member  and  the  controlling 
dashpot,  during  engagement  and  disengagement.  Lock  in  and  lock  out  devices  are 
also  included  and  the  simulation  responds  in  the  appropriate  manner  to  requests 
for  their  operation. 

The  shaft  brake  is  an  air-operated  disc  unit  mounted  on  the  output  half  of 
one  of  the  intermediate  shafts.  The  simulation  models  the  torque  characteristics 
of  the  brake  unit  as  a  function  of:- 

i.  the  number  of  pads 

ii.  the  brake  air  pressure 

iii.  brake  friction  coefficient 
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FIGURE  5  S  GaG  TURBINE  FUEL  CONTROL  SYSTEM. 
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The  friction  coefficient  varies  as  a  function  of  temperature  and  the  simulation 
taKes  account  of  these  effects  by  calculating  both  surface  and  bulk  temperatures 
which  vary  as  a  function  of  time  and  power  absorbed, 

CONTROLLABLE  PITCH  PROPELLER  (PITCH  CONTROL  SYSTEM) 

The  controllable  pitch  propeller  mulation  is  based  upon  the  characteristics 
of  the  Stone  Manganese  Marine  Engineering  Ltd  open  circuit  hydraulic  system.  The 
system  is  designed  around  an  open  centre  spool  valve  which  is  used  to  control  the 
flow  of  hydraulic  oil  to  a  servo  motor  mounted  in  the  propeller  hub.  Displacement 
of  the  servo  motor  varies  the  applied  pitch  angle.  The  system  uses  three  fixed 
displacement  screw  pumps,  two  being  electrically  motor  driven  and  one  geared  to  the 
propeller  shaft;  these  pumps  may  be  used  in  any  combination.  A  block  schematic  of 
the  system  is  shown  in  Fig  7,  from  which  it  may  be  seen  that  the  system  consists  of 
two  closed  loop  servos  connected  in  series.  The  first  is  an  electronic  actuator 
which  converts  the  electrical  pitch  demand  signal  into  mechanical  displacement  of 
the  input  rack.  The  second  is  a  hydro  mechanical  system  containing  the  spool  valve 
and  the  hub  servo  motor  with  feedback  in  the  form  of  mechanical  displacements 
transmitted  from  the  hub  servo  motor  via  the  oil  transfer  tubes  passing  through  the 
centre  of  the  propeller  shaft. 

A  functional  element  diagram  of  the  CPP  simulation  is  shown  in  Fig  8.  The 
spool  valve  has  been  modelled  using  a  measured  pressure/displacement  characteristic 
which  ia  modified  by  the  flow  rates  occurring  in  the  system,  ie  by  the  pump  output 
flow  rates  and  the  flow  to  and  from  the  hub.  The  hydraulic  load  placed  on  the 
system  is  a  function  of  both  the  propeller  spindle  torque,  which  is  supplied  by  the 
hull/propeller  simulation,  and  the  various  friction  components  present  in  the 
system. 


In  order  to  obtain  stable  operation  of  the  simulation  the  time  step  has  been 
reduced  to  40  milliseconds.  The  simulation  is  required  to  complete  three  cycles 
per  system  time  step  however,  communication  to  the  control  unit  and  to  the  master 
computer  still  only  occur  once  every  system  time  step. 

HULI/ PROPELLER 

The  load  on  the  system  is  modelled  in  the  hull/propeller  simulation.  This 
consists  of  a  number  of  look  up  tables  which  define  the  propeller  torque  and  thrust 
characteristics  in  the  form  of  the  modified  torque  and  thrust  coefficients,  Kq’ 
and  Kt1  as  functions  of  the  propeller  speed  of  advance  J*  for  various  angles  of 
applied  pitch.  The  simulation  also  contains  data  relating  to  the  hull  resistance 
characteristics  and  to  the  spindle  torque  characteristics  for  use  in  calculating 
the  load  experienced  by  the  controllable  pitch  propeller. 

A  second  order  interpolation  routine  is  used  to  provide  estimates  of  shaft 
torque,  thrust,  propeller  spindle  torque  and  ship's  speed  based  on  values  of  shaft 
speed,  pitch  angle  and  previous  ship's  speed. 

ELECTRONIC  INTERFACES 

Signals  that  pass  between  the  control  units  and  the  plant  can  be  considered 
to  be  one  of  four  different  types? - 

1.  discrete  level  outputs,  commands  to  open  valves,  switch  motors  on  etc. 

2.  discrete  level  inputs,  status  information  as  to  whether  a  valve  is  open 
or  closed,  whether  a  motor  is  running  or  stopped. 

3.  continuous  analogue  outputs,  control  demands  for  fuel  flow  or  pitch 
demand. 
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4.  continuous  analogue  inputs,  voltage  signals  from  pressure  gauge  transducers 
of  thermocouples,  frequency  signals  from  speed  probes  etc. 

In  order  for  the  simulations  to  respond  to* and  supply  all  the  signals  that  would 
normally  pass  between  the  control  units  and  the  plant,  a  considerable  amount  of 
interface  electronics  has  been  developed  to  convert  the  control  signals  into  a  form 
that  are  mutually  acceptable  to  both  control  unit  and  simulation  computer. 

Each  of  the  five  mini  computers  containing  the  plant  simulations  is  housed  in 
a  separate  cabinet.  Four  of  these  are  similar  to  that  shown  in  Fig  9  while  the 
fifth,  the  hull/ propeller  simulation,  does  not  have  to  communicate  with  a  control 
unit  and  therefore  does  not  reouire  the  signal  convertion  equipment.  The  interfaces 
for  each  simulation  are  shown  in  Fig  10  with  the  hardware  being  identical  between 
the  cabinets. 

With  respect  to  the  simulation  the  discrete  input  signals  are  at  24  V  levels, 
these  are  conditioned  and  fed  via  optical  isolators  to  standard  computer  interface 
cards  at  TTL  levels.  The  discrete  output  signals,  initially  at  TTL  levels,  are 
again  optically  isolated  and  used  to  drive  relays  to  present  no-volt  contacts  for 
use  by  the  control  unit.  Provision  has  been  made  for  up  to  16  discrete  input  and 
16  discrete  output  channels. 

Analogue  inputs  to  the  simulation  are  accepted  through  analogue  isolation 
amplifiers  and  conditioned  to  be  between  0  and  5  V.  These  signals  are  then 
digitised  via  a  10  bit  A/&  converter;  up  to  four  channels  of  analogue  input  are 
available. 

Each  analogue  signal  to  the  control  unit  is  supplied  by  an  individual 
conditioning  amplifier  housed  in  the  simulation  cabinet.  These  conditioning 
amplifiers  have  output  characteristics  that  simulate  the  specific  transducer 
characteristics  normally  used  to  measure  the  parameter  value  on  the  plant.  In  all, 
four  different  types  of  amplifier  were  required  to  simulate: 

a.  thermocouples,  millivolt  outputs. 

b.  resistance  temperature  bulbs,  outputs  equivalent  to  resistance  change. 

c.  pressure  transducers,  voltage  output. 

d.  magnetic  reluctance  speed  probes,  frequency  output. 

Up  to  sixty  control  system  inputs  can  be  accommodated  but  because  of  restrictions 
on  the  number  of  D/A  converters  available  only  sixteen  independent  parameters  can 
be  output  from  the  simulation  at  any  one  time.  To  overcome  this  limitation  a  pin 
board  matrix  has  been  used  whereby  any  number  or  combination  of  the  output 
amplifiers  may  be  driven  from  any  one  of  the  sixteen  input  channels.  For  example, 
in  the  case  of  the  gas  turbine,  the  control  unit  expects  to  receive  some  twelve 
values  of  power  turbine,  entry  temperature  (T6).  As  the  simulation  only  produces 
one  estimate  of  this  value,  the  pin  board  is  used  to  parallel  the  twelve  output 
amplifiers  supplying  rhe  T6  values  to  the  control  unit*  from  the  single  drive 
channel  being  supplied  by  the  simulation. 

Identical  hardware  is  used  within  each  simulation  cabinet  and  the  cabinets 
only  become  specific  by  way  of  the  simulation  software  and  pin  arrangement  on  the 
matrix  board  together  with  the  combination  of  output  amplifiers. 

These  interfaces  also  contain  test  mode  switches  which  allow  each  signal 
passing  between  the  simulations  and  the  control  units  to  be  interrupted  and  test 
signals  to  be  injected.  In  this  manner  the  simulations  and,  if  necessary,  the 
control  units  can  be  tested  independently  of  each  other. 
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FIGURE  9:  SIMULATION  CABINET. 
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SYSTEM  OPERATION 


Control  of  the  simulation  facility  is  effected  fro®  a  master  console 
connected  to  the  central  computer.  From  this  console  the  simulations  can  he 
run  and  control  is  exercised  as  to  which  parameters  are  sent  from  the  simulations 
to  the  master  computer  for  display  and  recording. 

A  minimum  number  of  parameters  are  always  sent  to  the  master  computer,  these 
represent  those  required  by  the  system  level  equations,  but  any  parameter  that  is 
calculated  within  any  of  the  simulations  is  available  to  be  sent  to  the  master  if 
required.  The  parameters  of  interest  will  vary  depending  upon  the  particular 
trial  being  performed  and  have  to  be  requested  either  at  the  beginning,  or  during  a 
trial. 


Parameters  that  are  sent  to  the  master  are  available  for  either: 

1.  display  of  current  value  on  a  VDU. 

2.  recording  on  an  analogue  pen  recorder, 

3.  recording  on  disc  for  subsequent  off-line  data  analysis. 

At  any  one  time  up  to  seven  parameters  may  be  displayed  on  the  VDU  with  eight  more 
on  the  pen  recorder  and  a  further  thirty  being  sent  to  disc.  The  off-line  data 
analysis  is  performed  on  another  mini  computer  which  has  extensive  data  analysis 
routines  for  manipulating,  displaying  and  producing  hard  copy  output  of  the  data. 

The  simulation  data  is  read  off  disc  in  the  master  computer  and  transferred  for 
analysis  via  a  serial  data  link. 

EVALUATION  CENTRE  USES 

At  present  the  first  of  the  prototype  propulsion  control  system  units  are 
being  installed  in  the  Evaluation  Centre.  In  the  first  instance  the  Centre  will  be 
used  simply  as  a  means  of  checking  that  the  units  do  perform  their  required 
functions.  This  will  lead  on  to  an  evaluation  of  the  control  philosophies  adopted 
and  to  studies  into  the  effectiveness  with  which  these  philosophies  have  been 
implemented  in  both  hardware  and  software  terms. 

Future  uses  of  the  Centre  will  include:  - 

1.  Failure  effect  studies;  with  facilities  to  enable  the  introduction  of 
machinery  faults  and  failures  into  the  plant  simulations  and  the 
opportunity  to  'manufacture'  faults  in  the  control  units  the  Centre  is 
ideally  suited  to  augment  failure  mode  and  criticality  analysis  which  tend 
in  general  to  be  paper  studies  only. 

2.  Ergonomic  studies  concerning  the  effectiveness  of  the  ship  operator 
interfaces  for  both  data  display  and  control  positions. 

3.  With  the  experience  gained  from  use  of  the  control  systems  at  the  Centre 
ship  operating  procedures  will  be  developed.  These  will  cover  all  forme 
of  plant  operation  from  remote  system  level  control  through  the 
reversionary  control  options  and  down  to  local  plant  level  control. 

A.  The  development  of  fault  finding  and  diagnostic  procedures;  as  in  1  above 
the  ability  to  easily  introduce  faults  into  the  system  will  be  exploited 
in  the  development  of  fault  identification  techniques  for  ship  operator/ 
maintainer  use. 
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5.  Once  the  control  systems  are  in  service  then  the  facility  provides  a  means 
of  investigating  in-service  faults  and  evaluating  any  possible  equipment* 
plant  or  control  system*  modification  prior  to  ship  implementation. 

In  general  the  Evaluation  Centre  is  capable  of  investigating  the  majority  of  areas 
concerning  the  man/control  system/plant  interactions.  The  Centre  is  not  laid  out 
like  a  ship  and  is  not  intended  to  consider  environmental  conditions  either  in 
terms  of  operator's  comfort  or  in  terms  of  electrical  interference  being  induced  in 
the  control  equipment. 

DISCUSSION 

With  the  facility  now  operational  and  with  the  benefit  of  hindsight  it  is 
possible  to  pick  out  the  good  and  bad  points  of  the  approach  adopted.  In  general 
the  philosophies  set  out  in  Ref  (1)  three  years  ago  have  been  adhered  to  with  only 
minor  modifications  being  introduced  to  produce  a  more  useful  facility. 

The  concept  of  the  individual  simulation  computers  connected  to  a  central 
master  has  worked  well.  With  this  arrangement  additional  machinery  items  can  be 
simulated*  as  the  need  arises,  by  attaching  additional  mini  computers  to  the 
master,  the  limiting  factor  to  this  arrangement  being  the  capacity  of  the  master 
computer.  By  using  a  fairly  large  mini  as  the  master;  extensive  data  recording  and 
display  facilities  have  been  possible. 

The  other  main  advantage  concerns  the  aise,  power  and  capacity  of  the 
simulation  computers  themselves.  The  computing  requirements  of  the  individual 
simulation  computers  are  determined  by  the  simulations  themselves  and  if  a 
simulation  expands  beyond  the  capacity  of  its  computer  then  that  particular  mini 
computer  can  be  upgraded  without  detriment  to  the  rest  of  the  system  and  at 
relatively  low  cost.  If  all  the  simulations  were  contained  in  one  large  computer 
and  the  simulation  requirements  outgrew  its  capacity  then  it  is  obviously  very 
expensive  to  replace  a  large,  powerful,  probably  main  frame  computer.  One  major 
lesson  learnt  during  this  project  was  that  the  requirements  of  the  simulations 
always  grew  and  never  reduce.  Fortunately  the  simulation  computers  that  were 
purchased  had  a  capacity  in  excess  of  the  original  estimates. 

It  was  intended  to  use  parametric  models  for  all  the  simulations*  namely 
models  that  define  the  plant  performance  in  terms  of  physical  characteristics  and 
properties.  Wherever  possible  this  objective  has  been  maintained*  however  in 
some  cases  this  has  not  been  possible  due  either  to  lack  of  data  or  timing 
considerations  in  order  to  maintain  real  time  operation.  The  most  notable 
deviation  was  in  the  case  of  the  gas  turbine  simulation.  This  simulation  was 
originally  of  the  lumped  parameter  type  described  by  Saravansmutto  and  Fauke,  Ref  (4) 
but  due  to  a  lack  of  data  defining  the  various  gas  generator  component  performance 
characteristics  over  the  wide  range  of  operation  reauired*  idle  to  full  power*  it 
became  necessary  to  use  a  very  much  simpler  transfer  function  type  model.  This  form 
of  model  is  stricily  only  valid  in  the  steady  stat^  with  the  engine  operating  on 
its  running  line  and  for  the  small  deviations  about  this  line  that  occur  during 
normal  transient  manoeuvres;  care  will  need  to  be  employed  in  the  interpretation  of 
the  results  obtained  during  failure  effect  studies  which  cause  the  gas  turbine 
simulation  to  deviate  wildly  from  the  operating  line. 

All  the  simulations  are  modular  in  structure  with  each  module  relating  to  a 
physical*  or  conceptual*  item  of  the  plant.  This  arrangement  has  the  advantage 
that  the  characteristics  of  specific  items  can  be  changed  with  ease.  In  some 
cases  the  simulations  were  developed  in  advance  of  the  plant  being  built  and  it  is 
intended  to  update  the  performance  characteristics  when  more  reliable  data  becomes 
available. 
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ABSTRACT 

Simulation  has  now  been  used  for  many  years  as  a  basic  tool  in  the  design 
of  warship  propulsion  control  systems.  This  paper  reviews  recent  experiences 
in  the  growth  of  importance  of  simulation  in  this  field,  including  those  brought 
about  by  the  recent  changes  in  digital  control  technology. 

INTRODUCTION 

Simulation  of  ship  and  propulsion  systems  has  wide  applications  in  ship 
design.  It  is  used  from  initial  feasibility  design  studies,  through  progressive 
design  stages  to  final  sea  trials  and  beyond,  the  models  growing  in  scope  and 
complexity  as  more  detailed  design  aspects  are  investigated.  Typical  areas  to 
which  simulation  is  now  being  applied  include: 

-  ship  performance  evaluation; 

-  propulsion  plant  performance  evaluation; 
propulsion  plant  selection  and  development; 
control  system  functional  design. 

control  system  development; 
control  system  setting  to  work. 

The  primary  advantage  of  using  simulation  models  of  ship  and  propulsion 
plant  lies  in  giving  design  teams  a  powerful  tool  for  the  prediction  of  steady  state 
and  transient  performance  of  the  whole  system,  including  dynamic  interactions. 
Simulation  accuracy  is  only  as  good  as  the  data  available  and  the  assumptions 
made,  but,  nevertheless,  it  does  allow  the  designers  to  make  the  best  use  of 
available  data  to  make  decisions  early  in  the  ship  design  phase. 

The  advent  of  digital  technology  for  warship  control  system  implementation 
has  placed  an  even  greater  emphasis  on  the  early  definition  of  the  functional 
requirements  of  the  control  system,  to  allow  for  the  greater  lead  times  required 
in  debugging  and  shore  testing  of  digital  systems.  In  addition  to  the  use  of 
simulation  models  for  control  system  functional  definition,  the  simulation  model, 
operating  in  real  time,  provides  a  relatively  inexpensive  "test  bench"  for  control 
system  development  and  testing- 

SIMULATION  MODELS 

A  ship  simulation  model  generally  consists  of  the  organisation  of  a  number 
of  program  modules,  each  module  representing  a  major  component  of  the  system. 
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such  as  hull,  propeller,  prime  movers,  shafting,  gearing  (with  associated 
clutches  and  Couplings  etc.  )  and  the  control  system.  Program  modules  have  been 
developed,  in  close  association  with  plant  manufacturers  and  research  establish^ 
ments,  for  a  wide  range  of  equipments  including; 

gas  turbines  :  industrial  and  aero  derivative; 

-  steam  turbines  and  associated  plant; 

diesel  engines  r  low,  medium  and  high  speed  types; 
gearboxes,  clutches,  fluid  coupling  and  convertors; 
electrical  transmissions  :  dc  and  ac; 
propellers  :  fixed  and  controllable  pitch. 

The  models,  where  possible,  have  been  validated  and  refined  using  model  and 
full  scale  plant  trials  data  of  steady  state  and  transient  performance. 

In  general,  the  program  modules  are  initially  of  the  theoretically  based, 
parameter  type  model  developed  from  first  principles.  The  use  of  suitable  trials 
data  may  allow  a  simplification  of  this  type  of  model  to  a  transfer  function  type 
which,  while  retaining  the  essential  model  characteristics,  generally  requires 
reduced  computational  time  and  capacity.  In  propulsion  control  system  studies  it 
has  been  found  that  because  of  the  sheer  size  and  computation  times  required 
program  modules  using  both  types  are  necessary,  but  with  the  use  of  transfer 
functions  being  encouraged  to  simplify  the  overall  model.  As  usual,  choices  are 
rarely  that  simple  and  compromises  are  made  using  judgements  consistent  with 
requirements  of  the  study. 

A  major  task,  prior  to  the  start  of  an  investigation,  is  to  determine  the 
simulation  basis  data  for  the  particular  application  and  its  validity.  Initially 
the  data  can  only  be  validated  at  the  model  formulation  stage  by  vetting  these  in 
the  light  of  previous  experience.  However,  data  for  the  prime  mover  models 
are  based  on  shore  tests  of  the  actual  items  of  plant  and  a  fair  degree  of  con¬ 
fidence  can  be  applied  to  (he  transfer  function  type  of  models  derived  from  these 
data. 


Propeller  characteristics  for  new  designs  are  usually  only  available  from 
physical  model  tank  tests  and  apply,  essentially,  to  steady  state  conditions. 

These  become  suspect  under  full-scale  and/or  transient  conditions  and  provide 
some  limitation,  as  is  well  known,  on  their  validity  for  manoeuvring  simulation. 
However,  comprehensive  studies,  both  model  and  full  scale,  have  been  under¬ 
taken  to  give  a  deeper  understanding  of  the  influences  of  scale,  transient  be¬ 
haviour,  cavitation  etc. 

These  studies  have  not  reached  their  conclusion,  but  already  some  of  the 
results  can  be  applied  to  identify  where  simulation  results  are  likely  to  be 
accurate  and  where  care  is  needed  in  their  interpretation.  It  has  been  found  that 
steady  state  operation  is  accurately  predicted,  that,  during  manoeuvring,  shaft 
speed  tends  to  be  reasonably  accurate  but  that  torque  and  particularily  thrust 
tend  to  be  overestimated.  When  examining  propeller  behaviour,  the  influence  of 
cavitiation  should  be  included  in  the  simulation  wherever  possible. 

It  is  vital  that  the  designer  should  be  fully  aware  of  the  importance  of 
model  validation  and  that  he  should  consider  measurement  and  recording  of  full 
scale  trials  results  an  essential  part  of  a  complete  study.  To  this  end  it  is  found 
necessary  to  maintain  a  team  of  trials  personnel  and  equipment  solely  for  the 
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purpose  of  data  acquisition  from  shore,  offshore  and  sea  trials.  In  addition  a 
comprehensive  suite  of  data  analysis  programs  are  used  to  provide  a  quantitative 
comparison  of  simulated  and  trials  results.  Typical  results  of  such  a  comparison 
for  a  COGOG  ship  during  a  crash  stop  transient  manoeuvre  are  shown  in  Figures 
1  and  2. 

A  collection  of  appropriate  program  modules  can  be  organized  into  a 
simulation  program  using  either  analogue,  digital  or  hybrid  computer  techniques 
in  continuous  or  discrete  simulations.  The  choice  depends  upon  the  nature  of  the 
study,  the  complexity  of  the  plant  and  system  being  modelled,  the  data  available 
and  the  presentation  of  results.  In  ship  propulsion  control  system  studies,  real 
time  operation  is  frequently  required,  e.g.  when  an  operator  and/or  control 
system  hardware  is  employed  in  the  simulation  loop.  In  addition,  the  increased 
complexity,  sophistication  and  refinement  of  program  modules  now  usually  means 
that  a  continuous  hybrid  computer  simulation  model  is  the  only  solution. 

For  a  typical  naval  ship  study  the  hybrid  models  are  now  sufficiently 
comprehensive  and  sophisticated  to  allow,  without  changes  to  the  model  structure, 
examination  of  ship  performance,  machinery  behaviour  and  control  system 
requirements,  when  operating  under  the  following  conditions: 

-  steady  state  operation,  twin  or  single  shaft,  differential  pitch  loadings; 

-  high  power  manoeuvring; 

*  harbour  manoeuvring; 

-  drive  mode  changeover; 
engine  load  sharing; 

-  control  system  failure  mode  and  effects, 

cyclic  propeller  2oading,  cavitation  effects,- 

-  propeller  shaft  stall  avoidance; 
clutch /coupling  duties; 

-  specific  prime  mover  loading  conditions. 

The  simulation  modules  and  techniques  described  above  have  been 
developed  from  experience  of  a  wide  range  of  propulsion  system  arrangements 
for  both  Royal  Navy  and  foreign  ships. 

APPLICATIONS  OF  SIMULATION  MODELS 

Performance  Evaluation  of  Propulsion  Machinery 

The  complete  simulation  model  is  built  up  of  modules  containing  the 
mathematical  models  for  each  major  item  of  propulsion  plant,  the  propulsion 
control  system  and  the  ship.  The  performance  of  each  module  can  be  evaluated 
either  individually  or  as  part  of  the  integrated  model.  Proposed  propulsion 
machinery  packages  can  thus  be  evaluated  to  establish  whether  the  performance 
is  within  the  bounds  of  the  required  propulsion  system  operational  envelopes  for 
each  drive  mode. 

Machinery  Selection  and  Development 

As  computer  capacity  and  speeds  increase,  so  could  the  complexity  of 
simulation  models.  This  increase  in  complexity  not  only  allows  more  accurate 
and  representative  models  of  major  items  of  propulsion  plant  to  be  produced, 
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but  also  provides  information  for  the  specification  and  selection  of  machinery 
components  and  their  auxiliaries.  Typical  examples  are  found  in  the  dynamic 
simulation  of  the  following  components: 

(a)  drive  friction  clutches  and  epicyclic  gearbox  brakes,  to  estimate  their 
dynamic  duties  during  a  range  of  drive  mode  changeovers  and  starting 
from  rest  thus  selecting  the  size  of  clutch  or  brake  and  developing  the 
control  modes  and  settings; 

(b)  shaft  and  transient  brakes, to  estimate  their  dynamic  duties  to  determine 
their  sizes,  cooling  and  their  limits  of  application; 

(c)  fluid  couplings,  to  estimate  the  dynamic  cooling  oil  supply  duties  during 
a  range  of  dynamic  manoeuvres  thus  sizing  the  cooling  oil  supply  system 
and  determining  the  control  system  requirements  to  maintain  the  coupling 
temperatures  within  design  limits. 

Control  System  Design 

The  almost  univei  sal  objective  of  all  ship  propulsion  control  systems  is  to 
achieve  a  good  and  consistent  ship  manoeuvring  capability  without  overstressing 
the  propulsion  plant.  The  strategy  selected  to  achieve  this  objective  is  a  major 
area  of  the  control  system  design,  irrespective  of  the  technology  of  implementation. 
The  control  strategy  is  generally  determined  for  the  propulsion  plant  operating  in 
its  normal  regime,  e.g.  open  sea  sprint  and  cruise  manoeuvres.  However,  the 
whole  operational  profile  of  the  ship  must  be  investigated  and  the  propulsion 
control  strategy  determined  to  suit.  For  example,  a  particular  ship  may  be 
required  to: 

(a)  operate  for  prolonged  periods  at  low  speeds  in  weather  conditions  which 
could  have  adverse  effects  on  a  diesel  engine; 

(b)  operate  quietly  at  certain  propeller  speeds. 

(c)  avoid  operation  at  a  critical  propeller  speed; 

Previously  the  control  strategy  and  development  would  have  been  conducted  with¬ 
out  knowing  how  the  propulsion  system  as  a  whole  behaved  and  the  control  system 
would  have  been  proved  only  during  sea  trials.  Using  simulation  methods  these 
tasks  can  be  conducted  in  the  ship  design  stages  thus,  also,  providing  an  early 
warning  of  propulsion  and  control  system  problem  areas. 

The  introduction  of  gas  turbine  and  high  speed  diesel  engines  to  the  marine 
propulsion  world  posed  new  control  problems.  With  simulation  models  providing 
a  better  insight  into  how  the  whole  propulsion  system  behaves,  these  difficulties 
have  been  largely  overcome. 

Gas  Turbine  Control  System  Design 

Early  gas  turbine  propulsion  systems  tended  to  adopt  rather  complex 
control  strategies  including  closed  loop  control  of  shaft  speed,  propeller  pitch 
rate  and,  in  some  current  designs,  even  closed  loop  control  of  torque.  However, 
there  exist  regimes  where  some  of  these  functions  acted  to  the  detriment  of  the 
propulsion  system,  e.g. 

closed  loop  control  of  shaft  speed  could  produce  transmission  overtorques 
during  high  speed  turning  manoeuvres; 

closed  loop  control  of  pitch  rate  resulted  in  the  fastest  rates  being  applied 
at  low  engine  powers  which  could  result  in  shaft  underspeeds. 

Although  there  have  been  vast  improvements  in  the  measurement  of  torque,  it  is 
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not  yet  considered  accurate  enough  to  use  as  a  controlling  variable. 

Experience  has  proved  that  good  ship  performance  could  be  achieved,  and 
the  control  system  reliability  could  be  improved,  by  pursuing  a  policy  of  careful 
control  simplification.  Gas  turbine  drive  system  control  functions  which  have 
proved  to  offer  good  ship  performance  are: 

open  loop,  rate  limited,  control  of  gas  turbine  power  demand; 

-  open  loop,  rate  limited,  control  of  propeller  pitch  demand; 

-  the  anticipation  of  pitch  reversal,  by  a  fixed  pitch  angle,  so  that  low 
shaft  speeds  are  avoided  by  the  early  re -application  of  engine  power 
during  ship  manoeuvres; 

power  limit  during  a  mismatch  of  propeller  pitches  for  combining 
gearbox  applications. 

Diesel  Engine  Control  System  Design 

The  power  to  weight  and  volume  advantages  of  industrial,  high  speed  and 
turbo-charged  diesel  engines  were  readily  recognised  when  they  were  applied  in 
the  marine  propulsion  field.  However,  the  transition  phase  brought  to  light  some 
control  problems  not  previously  appreciated.  The  major  problem,  especially  in 
CODOG  applications,  was  to  achieve  satisfactory  load  control  where  high  governor 
gains  resulted  in  large  fuel  rack  movements  for  small  engine  speed  changes,  and 
there  was  a  relatively  small  margin  between  the  propeller  load  line  and  the  turbo¬ 
charger  surge  line. 

Simulation  of  complete  diesel  engine  propulsion  systems  driving  via 
controllable  pitch  propellers  showed  that,  with  the  introduction  of  additional  fuel 
rack/engine  speed  load  control  functions  to: 
reduce  demanded  pitch  rate; 
hold  pitch  demand; 
pay  off  pitch  demand; 

stable  acceleration  and  pitch  reversal  manoeuvres  could  be  achieved  while 
maximising  the  available  drive  torque. 

Control  System  Optimisation 

Control  functions,  like  those  described  above,  are  used  in  the  propulsion 
system  simulation  model  to  form  a  control  system  basis.  From  this  basis,  a 
controls  parametric  sensitivity  analysis  is  conducted  to  optimise  the  control 
system  settings  for  the  particular  ship  and  propulsion  system  design.  This 
analysis  is  conducted  by  studying  the  effect,  on  ship  and  propulsion  system 
variables,  of  each  control  system  parameter  over  its  full  range  of  settings  for  a 
series  of  simulated  transient  manoeuvres.  An  example  of  the  effect  of  one  such 
parameter  is  shown  in  Figure  3  where  the  range  of  simulated  propeller  speeds 
and  thrusts,  obtained  by  varying  demanded  pitch  stroking  rate  settings,  are 
traced  for  a  typical  CODOG,  CPP  frigate. 

The  results  of  this  parametric  study  are  used  to  derive  the  initial 
optimum  control  system  settings  which,  based  on  the  best  available  data,  are 
recommended  to  achieve  the  major  objective  of  a  ’’good  and  consistent  ship 
manoeuvring  capability  without  overstressing  the  propulsion  plant", 

D1  3-5 


Failure  Analysis 

An  integral  part  of  control  system  development  is  to  conduct  reliability 
assurance  studies  to  estimate  the  reliability  of  a  proposed  control  system  and 
identify  its  critical  failures.  One  standard  practice  for  this  work  is  to  adopt  the 
procedures  contained  in  MIL  STD  1629A  to  conduct  failure  mode  and  effect  analyses. 
However,  a  difficulty  in  these  analyses,  when  applied  to  dynamic  systems,  is  to 
quantify  the  effect  of  failures,  especially  if  they  occur  during  transient  manoeuvres. 
In  these  cases  an  ideal  solution  is  to  employ  the  simulation  model  where  the  effects 
of  failures,  single  or  multiple,  can  be  quantified  economically  and  safely.  A 
typical  example  of  the  output  of  one  such  study  is  shown  in  Figure  5,  where  the 
potentially  damaging  effects  of  one  gas  turbine,  high  pressure,  shut-off  cock 
(HPSOC)  failure  during  a  simulated  crash  stop  manoeuvre  for  a  CODOG  frigate, 
is  seen  causing  significant  CPP  shaft  reversal. 

CONCLUSIONS 

One  of  the  most  important  lessons  learnt  in  this  work  over  the  last  ten 
years  is  that  propulsion  control  systems  should  be  kept  as  simple  as  possible, 
thus  minimising  running  maintenance  and  increasing  system  reliability.  This  aim 
is  stressed  as  the  growth  of  digital  system  capacity  makes  the  temptation  to 
utilise  that  increased  power  with  more  and  more  complex  controls,  harder  to 
resist. 


The  role  of  simulation  models  in  control  system  design  and  development  is 
assuming  more  importance  with  the  growth  of  digital  systems.  Now,  more  than 
ever,  the  economic  arguments  for  employing  real  time  simulation  models  for 
control  system  development  and  setting  to  work  as  well  as  in  the  functional  design 
stages  are  valid,  and  it  is  foreseen  they  will  continue  to  be  so. 

As  the  uses  of  simulation  models  increase  so  the  need  for  continual  data 
update  and  validation  increases.  To  this  end  the  feedback  of  ship  and  propulsion 
plant  trials  results  is  essential. 
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Figure  4  -  Distributed  Digital  Control  System. 
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A  NEW  INTEGRATED  MONITORING  SYSTEM 


by  Lyle  W.  Ferguson,  P.E. 
TANO  Corporation 


ABSTRACT 

This  paper  describes  the  propulsion  control  and  monitoring 
system  developed  by  TANO  Corporation  for  the  American  President 
Lines,  Ltd.,  containerships  currently  under  construction  at 
Avondale  Shipyards,  Inc.  The  system  incorporates  both 
conventional  alarm  and  monitoring  functions  and  a  Plant  Management 
System  (PMS)  that  uses  a  distributed  processing  microcomputer  and 
minicomputer  combination  to  provide  monitoring  and  data/alarm 
logging.  The  PMS  includes  multiple-color  cathode-ray  tube  (CRT) 
displays  and  continuous  storage  of  plant  performance  data  on 
magnetic  tape  cartridges  for  off-line  trend  analysis. 

The  paper  also  describes  the  development  of  system 
partitioning  into  vital  (conventional)  and  non-vital  (PMS) 
subsystems,  power  distribution  design,  and  the  PMS  system. 
Discussion  of  the  PMS  will  illustrate  the  use  of  the  distributed 
processing  scheme  within  the  console,  the  menu  format  used  for 
operator  interface,  and  the  hardware  methods  which  ensure  partial 
system  operation  if  the  host  or  satellite  computers  (CPUs)  fail. 

Color  graphics  on  the  CRT  units  provide  operators  with 
complete  information  concerning  particular  systems  (for  example, 
lube  oil  purification).  Implementation  and  development  of  PMS 
graphics  is  discussed  in  detail.  The  PMS  discussion  includes 
details  of  the  joint  experiment  by  the  shipyard,  shipowner,  and 
TANO  to  provide  a  remote  color  CRT  in  the  engineers'  quarters. 

Maintenance  and  diagnostic  features  and  system  reliability 
are  discussed.  Features  included  in  the  system  to  allow  the 
operator  or  technician  to  perform  system  checks  are  also 
explained. 

The  development  of  computer  controls  in  ship  propulsion 
systems  is  discussed  and  compared  to  the  development  of  computer 
control  pipeline  systems.  A  discussion  of  the  evolution  of 
pipeline  systems  provides  a  thesis  from  which  to  forecast  the 
future  of  shipboard  systems. 

INTRODUCTION 

This  paper  presents  the  design  and  system  features  of  the 
Propulsion  Control  and  Monitoring  system  supplied  by  TANO 
Corporation  for  the  new  American  President  Lines,  Ltd., 
containerships  being  constructed  at  Avondale  Shipyards,  Inc.,  in 
New  Orleans,  Louisiana,  U.S.A.  The  system  supplied  is  in  the  form 
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of  four  consoles:  two  in  the  machinery  space  control  room  and  two 
in  the  pilothouse.  This  is  a  relatively  extensive  system,  with 
over  1200  points  monitored  and  displayed.  It  is  one  of  the  larger 
systems  yet  built  by  our  company.  This  system  will  monitor  one  of 
the  first  slow-speed  diesel  installations  to  be  operated  by 
American  President  Lines,  Ltd.  Thus,  it  was  decided  to  provide 
extensive  remote  monitoring  capability  for  these  ships. 

The  following  sections  of  the  paper  will  briefly  describe  the 
ship,  vital  and  non-vital  console  systems,  and  details  of  the 
vital  and  non-vital  monitoring  systems.  We  shall  describe  the 
computer  system  and  CRT  system  used  and  provide  some  thoughts 
about  the  future  of  marine  systems  as  an  extension  of  contemporary 
shore-'based  systems. 

The  system  supplied  to  American  President  Lines,  Ltd., 
includes  the  following  major  subassemblies. 


1) 

Engine  Room  Console 

(ERC) 

2) 

Liquid  Transfer  Console 

(LTC) 

3) 

Watch  Officer’s  Console 

(WOC) 

4) 

Conning  Console 

(CC) 

5) 

Engineers'  Accommodation  Panels 

(EAP) 

6) 

Fire  Panel 

(FP) 

7) 

Bow  Thruster  Panel 

(BTP) 

8) 

Fuel  Fill  Station  Panels 

(FFSP) 

9) 

Loose  Parts 

10) 

Spares 

11) 

Trend  Data  Analysis  Computer 

The  ERC  and  LTC  are  located  in  the  main  engine  control  room 
on  the  port  side  of  the  ship  at  the  32 '-7"  level  and  are  arranged 
so  that  the  operator  is  facing  inboard  (the  machinery  space  can  be 
seen  through  glass  windows  located  behind  the  console).  The  WOC 
and  CC  units  are  located  in  the  bridge  area  at  the  113  foot  level, 
both  facing  forward.  It  is  expected  that  the  Trend  Data  Analysis 
Computer  will  be  located  in  the  Chief  Engineer's  office  area.  The 
unit  is  relatively  portable  and  can  be  moved  to  the  Main  Engine 
Control  Room  if  desired,  or  used  on  land. 

The  ERC  and  LTC  are  each  contained  in  modular,  11-gage  steel 
structures  which  support  all  components,  wiring,  and  printed 
circuit  modules.  No  external  equipment  cabinets  are  needed.  All 
transducers  are  located  in  the  machinery  space.  The  Bridge 
consoles  (WOC  and  CC)  are  also  fabricated  of  11-gage  steel.  All 
equipment  is  mounted  within  the  consoles.  The  various  auxiliary 
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panels  are  mounted  in  NEMA  4  and  NEMA  12  enclosures  depending  on 
location  and  function.  Figure  1  is  a  photograph  of  the  second 
shipset  ERC  and  LTC  in  the  final  assembly  area  at  our  plant. 


These  consoles  are  currently  being  checked  out  on  board  ship. 
Sea  trials  are  expected  to  take  place  in  the  spring  of  1982. 


SHIP  DESCRIPTION 

The  American  President  Lines,  Ltd.,  containe r ships  are  single 
screw,  860  feet  (approximately  265  meters)  long  overall,  and 
displace  39,900  long  tons.  The  ships  carry  Avondale  Shipyards, 
Inc.,  designation  C9-21 5  and  are  designated  MARAD  hull  numbers 
348,  349,  and  350. 

The  12-cylinder  Sulzer  12RND90M  engines  are  rated  at  43,200 
hp  (metric)  at  126  rpm.  The  engines  have  a  900-mm  bore  and 
1550-mm  stroke.  Brown-Boveri  turboblowers  provide  a  scavenge  air 
pressure  of  27.6  psi  (1.90  bar}  at  rated  power  conditions . 
Projected  fuel  consumption  on  the  engine  is  0.34  to  0.36  Ib/bhp-hr 
(150-160  gr/bhp-hr).  Auxiliary  heating  is  obtained  from  an  engine 
waste  heat  boiler  and  a  fully-autoroatic  fired  boiler.  The 
generating  plant  consists  of  three  2500-kw  diesel  plants  and  a 
1500-kw  steam  turbogenerator.  A  1500-kw  emergency  diesel 
generator  plant  is  also  provided.  All  cooling  water  pumps,  fuel 
oil  pumps,  and  other  vital  auxiliaries  are  fitted  in  duplicate 
with  auto-start  systems.  This  duplication  ensures  redundancy  and 
is  a  USCG  requirement  for  unattended  machinery  plant  operation. 
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SYSTEM  SUBDIVISION 

Early  in  the  planning  stages  of  this  system,  it  became 
apparent  that  a  computer  system  would  be  required  for  the 
extensive  data  and  alarm  logging,  trend  data  collection,  and  CRT 
displays  desired.  The  typical  design  question  is  whether  or  not 
all  the  alarm  systems  should  be  handled  by  the  computer  hardware 
and  software.  If  all  alarms  and  monitoring  are  operated  by  the 
computer  (known  as  a  scanning  system) ,  the  possibility  exists  that 
a  single  CPU  (central  processing  unit)  failure  can  disable  all 
functions.  This  is  obviously  not  a  situation  that  is  desirable? 
especially  with  the  trend  toward  reduced  manning. 

A  typical  way  of  overcoming  the  possibility  of  disabling  the 
computer  systems  is  to  install  a  backup  CPU  with  automatic 
changeover  capability  in  event  of  failure.  Since  the  CPU  is  not 
the  only  "link"  in  the  data  acquisition  and  display  chaii,  the 
backup  system  approach  can  be  taken  as  far  as  one  desires. 
Systems  have  been  built  with  backup  CPUs,  storage  discs,  etc.,  all 
the  way  to  end  elements  such  as  transducers.  In  the  planning 
stage,  system  cost  has  to  be  considered  along  with  probable 
failure  modes  and  overall  reliability;  at  this  point,  judgements 
are  made  which  usually  lead  to  system  configurations  which  meet 
functional  requirements  and  cost  constraints. 

The  choices  made  for  this  system  have  led  to  a  system  design 
which  is  divided  into  vital  and  non-vital  subsystems.  In  general, 
the  vital  system  performs  the  alarm  and  monitoring  functions 
required  by  USCG  NVIC  1-69,  "Guide  for  the  Automation  of  Main  and 
Auxiliary  Ship's  Machinery"  and  the  non-vital  systems  (PMS-Plant 
Management  System)  performs  all  other  alarm  and  monitoring 
functions. 

The  vital  system  is  constructed  around  TANO's  Series  79 
printed  circuit  module  family,  which  provides  a  complete  signal 
conditioning  and  alarm  function  on  each  printed  circuit  module. 
This  hardware  is  already  in  service  in  several  marine 
applications. 

The  non-vital  system  is  designed  using  TANO's  high  density 
IRTU/TDAC  SCADA  hardware,  which  has  been  proven  in  pipeline 
monitoring  and  control  applications.  This  hardware  line  has  also 
been  applied  successfully  on  a  barge-mounted  LNG  plant,  which  has 
been  operating  in  Indonesia  for  several  years.  The  non-vital 
system  includes  a  Digital  Equipment  Corporation  (DEC)  LSI-11/23 
16-bit  minicomputer,  two  Intelligent  Systems  Corporation  (ISC) 
color  CRT  displays,  two  Xerox  printers,  and  a  DEC  TU-58  magnetic 
tape  cartridge  drive.  These  units  were  all  selected  based  on  past 
experience  with  either  these  particular  items  or  similar  equipment 
from  the  same  manufacturer.  NOTE;  DEC  and  LSI-11  are  registered 
trademarks  of  Digital  Equipment  Corporation. 
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Figure  2  shows  the  system  configuration  and  illustrates  the 
interconnects  between  vital  and  non-vital  systems,  the  IRTU 
(intelligent  remote  terminal  unit),  and  the  host  computer.  The 
vital  system  (shown  on  the  left  side  of  figure  2)  is  connected 
directly  to  all  vital  sensors.  Each  Series  79  module  incorporates 
a  signal  conditioner  and  alarm  logic  to  drive  annunciator  lights 
and  horns  directly,  and  includes  first  out  and  summary  alarm 
capability.  Auxiliary  outputs  for  analog  and  digital  data  and 
alarm  logging  are  connected  to  the  non-vital  system  IRTUs. 

The  non-vital  system  consists  of  six  primary  data  acquisition 
and  display  units  (IRTUs),  the  host  computer,  and  the  output  and 
command  devices  attached  to  the  host  computer.  The  IRTUs  accept 
analog  and  digital  data  from  sensors  and  from  the  non-vital 
system.  Each  IRTU  includes  a  microcomputer  which  allows  it  to 
function  in  a  stand-alone  mode.  The  IRTU  provides  the  following 
functions  without  aid  from  the  host  computer: 

1)  Alarms  for  both  analog  and  digital  data  types. 

2)  Analog  meters  for  selected  points. 

3)  Demand  displays  for  all  points  in  the  IRTU,  including 

changeable  setpoints,  deadband,  and  time  delay. 

English/metric  unit  conversions  are  included. 

I  4)  Self  diagnostics  of  IRTU,  CPU,  and  signal  conditioning 

I  hardware. 

f 

5)  Self-monitoring  of  CPU  failure, 
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Each  IRTU  is  connected  to  the  host  computer  using  RS232 
serial  communication  lines.  These  lines  are  used  to  transmit  to 
and  receive  data  from  the  host  computer.  The  host  computer 
"polls"  the  iRTUs  in  a  "round-robin"  fashion  to  gather  all  field 
data  for  display  and  logging  purposes. 

The  host  computer  communicates  with  the  following  peripheral 
devices  through  the  serial  communications  lines: 

1)  6  IRTUs  -  data  gathering 

2)  2  CRTs  -  data  display  and  control 

3)  2  Printers  -  logging 

4)  1  Remote  CRT  -  remote  data  display 

5)  1  Master  Clock  -  synchronization 

6)  1  Watchdog  Timer  Module  -  CPU  failure  detection 

These  devices  and  the  associated  interconnection  scheme  are 
shown  in  the  right-hand  side  of  Figure  2. 

The  vital  and  non-vital  systems  are  connected  in  two  ways. 
First,  all  alarm  states  and  analog  values  are  passed  from  the 
vital  system  to  the  non-vital  system  for  logging  purposes. 
Second,  each  IRTU  includes  a  "watchdog  timer"  in  software  to 
create  a  contact  closure  every  15  seconds.  This  contact  closure 
is  used  as  a  vital  alarm  system  input.  The  alarm  channel 
connected  to  this  input  is  adjusted  so  that  the  time  delay  is 
greater  than  15  seconds  and  thus  only  enters  the  alarm  state  if 
the  contact  fails  to  close  once  during  the  15-second  period.  The 
host  CPU  has  a  similar  monitor  through  the  vital  system.  It  is 
connected  to  a  hardware  "watchdog  timer"  module  via  a  serial 
communication  line.  If  the  host  CPU  fails  to  send  a  message  to 
the  watchdog  timer  module  every  15  seconds,  a  vital  alarm  contact 
is  opened,  and  the  host  CPU  is  declared  "failed." 

The  system  subdivision  used  is  designed  to  allow  orderly 
system  degradation  without  the  failure  of  any  one  subsystem 
affecting  the  operation  of  the  other.  By  operating  the  non-vital 
system  in  a  distributed  processing  manner,  an  IRTU  can  fail 
without  affecting  the  alarm  or  display  capabilities  of  the  other 
IRTUs,  or  the  display  and  alarm  capabilities  of  the  host  computer. 
If  an  IRTU  is  "off-line"  this  is  detected  at  the  host  computer  and 
the  message  "COMMUNICATIONS  FAILED  RTU  #N"  appears  on  the  CRT.  If 
the  host  CPU  fails,  each  IRTU  will  continue  to  operate  and  all 
alarm  and  local  display  capability  will  remain;  only  logging, 
trend  data  collection  and  summary  display  capability  will  be  lost. 

The  system  subdivision  chosen  provides  the  added  capability 
of  the  computer-driven  system  and  retains  the  simplicity  and 
reliability  needed  for  the  vital  alarm  and  monitoring  points.  The 
further  subdivision  of  the  non-vital  system  into  intelligent 
data-gathering  subsystems  connected  to  a  host  CPU  provides  further 
protection  against  a  single  failure  causing  the  loss  of  the 
non-vital  alarm  and  monitoring  system. 
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Vital  System 

The  Concept*  The  Secies  79  Marine  Monitoring  System  was 
specifically  designed  to  provide  reliable  monitoring  and 
annunciator  operation  in  a  shipboard  environment.  Simplicity  is 
the  primary  basis  of  the  Series  79  concept. 

Overall  system  design,  including  component  selection,  is 
directed  toward  extended  operation  in  the  marine  environment. 
Temperature  extremes,  vibration,  position,  oily  vapors,  high 
humidity  and  fluctuating  power  systems  have  virtually  no  effect  on 
system  operation.  Series  79  meets  all  regulatory  body  operational 
and  environmental  requirements  and  is  suitable  for  use  in 
unattended  machinery  space  systems.  Long  system  service  life  is 
assured  by  conservative  rating  of  system  components  for  the  harsh 
marine  environment.  Liberal  use  of  military  grade  components  and 
conformal  coating  of  electronic  circuits  assures  high  reliability. 

Except  for  common-function  buses  such  as  lamp  test,  alarm 
acknowledge,  main  power,  etc.,  each  module  is  totally  independent 
of  all  other  modules  in  the  system.  Each  module  is  essentially 
self-contained.  A  monitoring  module  failure  can  only  affect  one 
parameter,  thus  simplifying  the  location  and  repair  of  the 
offending  circuit. 

The  Series  79  system  consists  of  a  monitoring  interface 
basket,  ten  individual  monitoring  modules,  and  the  system 
descriptive,  application,  and  maintenance  documentation.  Support 
items  such  as  power  supplies,  meters,  indicators,  etc.,  are 
selected  from  numerous  readily  available  standard  sources  by  the 
system  designer  to  satisfy  individual  system  specifications. 
System  sensors  are  also  selected  by  the  system  designer  to  fit 
particular  applications. 

The  monitoring  interface  basket  contains  the  Series  79 
modules  and  provides  both  interface  terminals  for  ship's  wiring 
from  sensors  and  terminals  for  connection  to  the  console  display 
devices.  This  unitized  construction  minimizes  console  and  panel 
wiring.  The  monitoring  interface  basket  easily  mounts  on 
bulkheads  within  consoles  and  panels,  and  provides  ready  access  to 
the  modules  for  servicing.  All  modules  plug  into  the  backplane 
and  can  be  quickly  removed  and  replaced.  Digital  programming 
switches  located  at  each  module  position  on  the  monitoring 
interface  basket  allow  the  module  functional  features  to  be 
tailored  individually.  Since  these  switches  are  on  the  basket, 
programming  is  assigned  to  the  position  and  not  the  module. 
Should  it  be  necessary  to  replace  a  module,  no  changes  in 
programming  are  required  to  make  the  replacement  module  perform 
like  the  original  module. 

Test  points  and  adjustments  on  Series  79  modules  simplify 
calibration  requirements.  Light  emitting  diodes  (LEDs)  are 
incorporated  on  the  front  of  the  modules  to  provide  instant 
operating  data  without  having  to  remove  the  module.  Ease  of 
calibration  and  servicing  are  key  aspects  of  all  system  module 
designs.  The  system  arrangement  is  shown  in  Figure  3. 
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Series  79  modules  are  divided  into  three  functional 
categories:  analog  monitoring  and  alarm;  contact  alarm,  alarm 

control,  and  summary  alarm;  and  setpoint-status/alarm.  Each  of 
these  module  groups  is  designed  to  satisfy  specific  marine 
monitoring  and  alarm  applications  requirements.  Typical  module 
block  diagrams  are  shown  in  Figure  4. 
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Analog  Modules.  Analog  monitoring  and  alarm  modules  provide 
for  continuous  or  demand  display  of  a  process  parameter  and  a  high 
or  low  alarm  function.  Series  79  modules  are  available  for  4-20 
mA,  type-J  thermocouple,  100  Ohm  Nickel  or  Platinum  resistance 
temperature  detector  (3-wire) ,  and  10  Ohm  Copper  resistance 
temperature  detector  (4-wire)  process  sensors.  This  allows  for  the 
monitoring  of  pressures,  temperatures,  levels,  flows,  and  other 
process  parameters.  Each  of  these  modules  contain  a  signal 
conditioner/linearizer  circuit,  a  setpoint  (alarm  trip)  circuit 
and  a  complete  annunciator  circuit.  Thus,  all  required  electronic 
circuitry  for  a  single  monitored  point  is  contained  on  one  plug-in 
unit. 


Analog  monitoring  and  alarm  modules  have  separate  outputs  for 
analog  displays  and  alarm  indication.  All  analog  modules  have  a 
master  zero  and  span  adjustment  to  provide  for  overall  calibration 
and  a  separate  meter  span  adjustment  to  compensate  for  the 
relatively  poor  tolerance  of  analog  meters.  In  addition,  setpoint 
and  deadband  adjustments  are  provided  to  set  the  alarm  trip  point 


D2  1-9 


and  reset  point.  A  test  point  on  the  module  allows  the  setpoint 
value  to  be  read  on  any  common  test  multimeter.  This  allows  the 
setpoint  to  be  readily  set  without  the  need  to  exercise  the 
process  or  connect  simulation  equipment  to  the  input  terminals. 
Each  analog  monitoring  and  alarm  module  contains  an  alarm  circuit 
which  is  essentially  identical  to  the  contact  alarm  module  circuit 
describea  below. 

Contact  Alarm  Modules.  Contact  alarm,  alarm  control,  and 
summary  alarm  functions  are  provided  by  three  separate  modules. 
The  contact  alarm,  whose  circuits  are  also  included  in  the  analog 
monitoring  and  alarm  modules,  is  used  to  provide  an  alarm  function 
from  a  switca  type  input.  Each  alarm  circuit  is  also  fitted  with 
an  inhibit  input  which  is  used  to  prevent  the  alarm  from  sounding 
under  specific  conditions,  such  as  when  equipment  is  deliberately 
secured.  Alarm  circuits  contain  numerous  installed  options  such 
as  "first  out/non-first  out",  "sealed/un-sealed" ,  and 
common/independent  horn  and  lamp  acknowledge.  These  programmable 
options  allow  the  system  to  be  tailored  to  specific  operating 
requirements . 

The  alarm  controller  is  utilized  to  provide  alarm  support 
functions  common  to  all  system  annunciators.  These  functions 
include  a  synchronized  blink  rate,  vital  and  non-vital  audible 
annunciator  drive,  and  buffering  of  the  system  test  and 
acknowledge  buses.  A  typical  system  requires  just  one  alarm 
controller . 

Where  remote  indication  of  the  activation  of  local  alarms  is 
required,  the  Series  79  summary  alarm  module  is  utilized.  This 
module  is  ideal  tor  summary  alarm  monitoring  of  the  ship's 
propulsion  plant  on  the  bridge. 

Setpoint/Status  Modules.  The  setpoint-status/alarm  group 
contains  three  highly  specialized  modules  which  are  used  in  less 
common  functional  applications.  These  functions  include  multiple 
setpoints  and  alarms  for  a  single  parameter,  digital  control  based 
on  a  process  setpoint,  and  operator  variable  setpoints. 

Power  Requirements.  Series  79  systems  utilize  a  source  of 
nominal  24  VDC  to  satisfy  all  operating  power  needs.  Each  module 
contains  its  own  power  regulator,  thus  permitting  wide  swings  in 
the  24  VDC  service  voltage.  Each  monitoring  interface  basket 
contains  a  main  fuse  and  power  failure  indicator.  Module  ship 
interface  lines  are  fuse-protected  from  short  circuits  and 
overloads . 

Module  Removed  Alarm,  It  is  possible  to  configure  a  system 
to  declare  an  alarm  when  a  module  is  removed  from  a  basket.  The 
Module  Removed  Alarm  module  provides  a  feedthru-f unction  for 
unused  slots,  if  this  function  is  required.  All  other  modules 
have  feed-thru  jumpers  in  one  pair  of  backplane  connections.  This 
type  of  module  may  be  connected  to  a  contact  input  to  cause  an 
alarm  if  a  module  is  removed  from  any  basket  in  a  system. 

Status  Indicators.  Light  emitting  diodes  (LEDs)  are  placed 
on  each  module  to  provide  the  operator  with  an  easy  method  of 
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checking  field  and  console  component  status  in  the  event  of  a 

malfunction  within  the  system.  These  LEDs  function  as  follows: 

1)  Status  (Yellow)  -  indicates  the  state  of  the  field 

sensor.  If  the  system  is  configured  for  normally  closed 
contacts,  this  LED  is  illuminated  when  the  contact  is 

open.  For  analog  inputs,  the  LED  indicates  that  the 

annunciator  circuitry  on  the  module  is  receiving  an 
off-normal  signal. 

2)  Horn  (Red)  -  indicates  an  unacknowledged  alarm  horn. 

3)  First  Out  (Red)  -  indicates  that  a  module  is  holding  the 
first-out  bus  signal. 

4)  P  Summary  (Red)  -  flashes  momentarily  when  alarm  occurs 
to  indicate  assertion  of  the  summary  bus. 

5)  S  Summary  (Yellow)  -  indicates  the  state  of  the  output 
driving  the  summary  bus, 

Non-Vital  System 

Capabilities.  The  non-vi tal  (PMS)  system  provides  the 
following  functions: 

1)  Signal  conditioning  and  alarm  indication  as  indicated  by 
machinery  space  sensors.  This  includes  sequential  horn 
and  lamp  acknowledge  summary  alarms  and  first  out 
notification. 

2)  Demand  digital  display  for  all  points  within  the 
non-vital  system,  including  variable  alarm  setpoints, 
time  delays,  deadbands,  and  English/metric  conversions. 

3)  CRT  displays  including  point  pages,  graphics  pages 
showing  real-time  system  data  superimposed  on  system 
piping  diagrams,  trend  data  displays,  system 
configuration  pages,  engine  performance  displays  and 
"help"  pages. 

4)  Printed  logs  including  data  and  alarm  logs,  alarm  summary 
logs,  pump  run  time  records,  and  backup  bell  logging. 

5)  Trend  data  collection  and  storage  of  data  on  magnetic 
tape  cartridges. 

Each  capability  will  be  explained  in  detail  in  the  following 
paragraphs.  All  of  the  functions  described  are  actually  performed 
by  software  operating  either  in  the  IRTUs  or  the  host  computer. 

Signal-Conditioning/Alarms .  Software  in  the  IRTU  implements 
the  same  functions  previously  described  for  the  Series  79 
hardware.  All  machinery  space  points  are  scanned  at  three-second 
intervals.  Analog  values  are  scaled  and  compared  to  setpoint 
values;  if  values  exceed  setpoints,  the  point  is  declared  as  an 
alarm.  Contacts  are  checked  for  status  and  compared  against  a 
table  of  acceptable  ,tates  adjusted  for  the  effect  of  any  inhibit 
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information.  After  all  points  have  been  checked,  time  delays  are 
considered.  If  points  have  been  in  the  alarm  state  long  enough, 
alarm  indicators  are  illuminated  and  the  alarm  horn  is  turned  on. 
Acknowledge,  first-out  and  summary  sequences  are  also  included  to 
duplicate  the  vital  system  features.  Data  is  sent  to  the  host 
computer  indicating  which  points  are  in  alarm  and  which  are  in 
alarm  unacknowledged.  A  message  will  appear  on  the  CRT  indicating 
"ALARM  ON  PAGE  SW."  The  operator  can  type  the  characters  SW  on 
the  keyboard  and  a  text  display  of  the  point  in  alarm  will  appear 
on  the  CRT.  The  host  computer  will  print  an  alarm  log  in  red  on 
the  printer.  Other  logs  in  progress  will  be  interrupted 
momentarily  while  the  alarm  log  is  printed.  After  the  alarm  has 
been  acknowledged,  the  special  CRT  message  will  disappear  although 
a  "point  log"  on  the  CRT  will  continue  to  show  the  point  in  the 
alarm  state  until  the  alarm  has  been  cleared. 

Demand  Displays.  The  demand  display  unit  includes  a  6  1/2 
digit  digital  display,  a  three  digit  address  thumbwheel,  a  four 
digit  setpoint  thumbwheel,  three  LED  unit  indicators,  and  six 
momentary  switches  to  allow  the  operator  to  examine  and  modify 
non-vital  system  setpoints,  deadbands  and  time  delays.  The 
address  of  a  point  may  be  dialed  into  the  address  thumbwheel  and 
the  current  value  will  be  displayed  on  the  digital  display. 
Analog  values  are  automatically  scaled  for  maximum  resolution; 
digital  values  (contact  inputs)  are  displayed  as  *0*  or  "1." 
Setpoints,  deadband  and  time  delays  may  be  examined  using  the 
"Display"  switches.  Values  may  be  changed  by  entering  the  new 
value  into  the  value  thumbwheel  and  depressing  the  "Load"  switch 
momentarily . 

Diagnostic  functions  include  a  quick  check  on  overall  IRTU 
status  by  dialing  address  "000"  into  the  demand  display 
thumbwheels.  A  repetitive  pattern  of  hexadecimal  digits  will 
indicate  that  the  IRTU  CPU  is  operating.  If  a  "calibration  in 
progress"  switch  is  actuated,  other  special  addresses  can  be  used 
to  drive  either  individual  meters  or  all  meters  to  values  selected 
by  the  value  thumbwheels. 

CRT  Displays.  CRT  displays  are  generated  by  the  host 
computer  using  data  transmitted  to  the  host  computer  from  each 
IRTU.  The  operator  may  select  "pages"  from  a  "menu"  ’which 
displays  the  choices  available.  There  are  three  basic  types  of 
data  available  to  the  operator  via  the  CRT.  One  type  displayed  is 
the  host  computer  configuration  pages.  This  display  allows  the 
operator  to  set  the  time  and  date,  recall  a  "data  base"  generated 
for  special  operation  conditions,  or  copy  tapes. 

A  second  type  of  data  available  is  in  the  form  of  tabular 
pages,  as  shown  in  Figure  5.  Data  logs,  point  displays,  trend 
data  displays,  alarm  summary  logs  and  pump  run  time  logs  are 
available  in  this  format.  Data  logs  and  point  displays  are 
"snapshots"  of  the  data  -  the  displays  are  not  updated  in 
real-time.  Trend  data  displays  are  generated  from  data  being 
collected  to  calculate  four-hour  and  24-hour  averages.  They  may 
be  recalled  from  tape  either  by  day  or  by  full  tape. 
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Figure  5 


The  third  display  available  is  the  system  graphic  display 
which  is  a  real-time  display.  Figure  6  shows  one  of  the  real-time 
displays.  These  displays  show  pump,  valve,  and  process  status  on 
graphic  displays  developed  from  actual  piping  diagrams.  Tank 
levels  are  shown  as  bars  whose  height  is  proportional  to  tank 
level.  The  symbols  on  the  diagrams  change  color  to  indicate 
status;  open  valves  or  running  pumps  are  shown  in  green,  closed 
valves  or  off-line  pumps  are  shown  in  red.  Analog  values,  such  as 
pump  discharge  pressures,  are  shown  in  red  if  values  exceed  alarm 
setpoints.  Each  display  is  updated  every  10  seconds.  All 
displays  may  be  seen  on  either  CRT  as  the  operator  desires. 
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Figure  C 


An  additional  real-time  display  is  the  engine  performance 
display.  This  display  plots  instantaneous  specific  fuel  flow  vs 
brake  mean  effective  pressure  and  allows  the  operator  to  compare 
performance  against  trials  data.  The  calculations  include  actual 
fuel  flow,  shaft  RPM,  and  horsepower  with  corrections  for  ambient 
temperature  and  pressure,  fuel  heating  value,  cooling  water 
temperature,  and  charge  air  temperature. 

Printed  Loos.  ’\utomatic  logs  are  available  at  preset 
intervals  of  from  1  to  24  hours  and  include  alarm  summary  (first 
40  alarms  in  the  interval)  ,  pump  run  times  and  averaged  data 
(4-houz  and  24-hour). 

Collection.  Trend  data  is  collected  on 
approximately  390  points  selected  by  the  owner.  Average  values 
are  calculated  on  these  data.  Every  four  hours  the  average  values 
are  stored  on  magnectic  tape  cartridges.  Twenty-four  hour 
averages  are  also  developed  and  stored.  No  calculations  are 
performed  on  the  data.  The  raw  data  is  stored  and  wil]  be 
interpreted  by  ship's  personnel  or  by  on-shore  personnel.  The 
data  may  be  examined  by  "dumping"  it  to  the  CRT  or  printer. 
Either  a  particular  day  or  a  whole  tape  may  be  selected ,  A  later 
addition  to  the  system  is  a  "trend  computer"  which  will  allow  an 
operator  to  select  a  particular  point  in  the  data  and  display  all 
days  of  that  data  for  comparison  purposes. 


IRTU  Hardware.  The  signal  conditioning  and  data  acquisition 
(SCADA)  functions  of  the  non-vital  system  are  accomplished  using 
six  IRTUs  (Intelligent  Remote  Terminal  Units)  located  in  the  rear 
of  the  ERC  and  LTC.  Each  IRTU  performs  the  signal  conditioning, 
alarm,  and  data  display  functions  previously  described.  The  IRTUs 
were  developed  using  a  combination  of  two  TANO  product  lines:  the 
Outpost  microcomputer  products  CPU  and  the  TDAC  data  acquisition 
system  hardware. 

The  Outpost  microcomputer  product  line  is  centered  around  the 
Motorola  6800  (and  its  derivatives)  8-bit  microprocessor  and 
includes  the  following  modules. 


1)  Central  Processor  -  microprocessor 

2)  Power  Regulator 

3)  Maintenance  Controller  -  interfaces  with  address  and  data 
register  panel 

4)  Bus  Controller  -  memory  refresh,  bootstrap  loader, 
real-time  clock 

5)  Memory  -  random  access  memory  (RAM),  64K  bytes  maximum 

6)  Memory  -  read-only  memory  (ROM),  64K  bytes  maximum 

7)  Serial  Line  interface  -  communications 

8)  TDAC  Interface  -  data  acquisition 

In  this  application,  the  processor  is  operated  at  a  1  Mhz 
clock  rate.  Memory  available  includes  32K  bytes  of  RAM  and  as 
much  as  32K  bytes  of  ROM.  Communication  within  the  console  is 
configured  for  a  rate  of  2400  baud.  The  TDAC  hardware  system 
consists  of  a  group  of  data  acquisition  and  interface  modules 
which  allows  the  CPU  to  acquire  both  analog  and  digital  data.  The 
modules  utilized  in  the  system  include  the  following: 

1)  Group  Selector  -  module  row  selector 

2)  Analog-to-Digital  (A/D)  Converter 

3)  Digital -to- Analog  (D/A)  Converter 

4)  Isolated  Analog  Multiplexer  -  8  channel 

5)  Isolated  Status  Input  -  32  channel 

6)  Thermocouple  Signal  Conditioner  -  8  channel 

7)  Latching  Command  Output  -  16  channel 

8)  Lamp  Driver  -  32  channel 

9)  RTD  Signal  Conditioner 

10)  Momentary  Command  Output 
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The  system  is  designed  to  appear  to  the  CPU  as  an  ordinary 
block  of  memory.  The  CPU  can  write  commands  to  and  receive 
information  from  each  location  using  standard  CPU  operations.  As 
used  in  the  IRTU,  the  data  acquisition  system  appears  as  a  512 
byte  memory  port  and  allows  access  to  up  to  256  analog  points  and 
2048  digital  points  in  a  typical  IRTU.  Digital  points  can  be 
scanned  at  a  rate  greater  than  500  points  per  second;  analog 
points  can  be  scanned  at  up  to  75  points  per  second.  All  scanning 
rates  depend  on  software  but  tend  to  be  limited  by  the  A/D 
conversion  and  multiplexing  delays. 


The  packaging  scheme  used  for  the  IRTUs  consists  of  a 
combined  CPU/TDAC  module  basket  associated  with  "expansion"  TDAC 
baskets.  Additional  rack-mounted  auxiliary  components  include  a 
maintenance  panel  and  power  distribution  assembly.  Interface  with 
ship's  wiring  is  accomplished  via  I/O  "frames"  which  connect  to 
ship's  wiring  on  one  side  and  to  multi-conductor  flat  cables  (from 
signal  conditioning  modules)  on  the  opposite  side.  This  is 
illustrated  in  Figure  7. 
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This  system  has  proven  to  be  very  versatile.  The  rack 
mounting  provisions  of  all  components  including  I/O  frames,  allows 
field  wiring  access  to  terminal  strips  while  providing  a  high 
density  flat  cable  connection  to  the  appropriate  signal 
conditioning  module. 

Hardware  troubleshooting  is  accomplished  using  the 
maintenance  panel  provided  as  part  of  each  IRTU.  This  panel  may 
be  used  to  examine  data  at  operator-selected  locations  in  the  IRTU 
and  may  deposit  data  at  operator  selected  locations.  This  feature 
may  be  used  with  the  processor  running  or  halted.  For  example,  if 
the  state  of  a  contact  input  is  questionable,  the  switch  panel  may 
be  used  to  look  at  a  bit  in  memory  which  represents  the  state  of 
the  contact.  A  light  on  the  maintenance  panel  will  be  on  or  off 
depending  on  contact  state. 

IRTU_Sof tware.  Software  for  the  IRTUs  is  written  in  Motorola 
6800  assembly  language  and  consists  of  tasks  which  operate  under 
priorities  and  schedules  set  by  TANO's  MIDGET  real-time  executive. 
The  tasks  are  as  follows. 

1)  Initialization 

2)  System  clock,  1/60 th  of  a  second  and  seconds 

3)  System  clock  seconds 

4)  Poll  digitals,  accumulators  and  analogs 

5)  Poll  analogs 

6)  D/A  driver 

7)  Into  alarm  and  out  of  alarm 

8)  Local  display 

9)  Poll  ship  speed 

10)  Local  command  (maintenance  panel) 

11)  Receive  communications 

12)  Communications 

13)  Ballast  heeling  system 

This  software  operates  with  a  default  data  base  which  is 
stored  in  ROM.  The  default  data  base  contains  all  preset  alarm 
setpoints,  time  delays  and  deadbands.  The  system  will  restart 
automatically,  using  these  values  after  a  power  failure  or  after  a 
manual  reset.  Operator-modified  setpoints,  etc.,  can  be  saved  on 
tape  by  the  host  computer  and  recalled  to  "downline  load"  each 
IRTU,  if  desired.  All  operating  programs  are  stored  in  ROM;  no 
program  "downline  loads"  are  necessary. 


The  communi cat ions  protocol  includes  many  message  types  but 
only  a  few  will  be  discussed  here.  (It  should  be  noted  that  all 
communications  are  initiated  by  the  host  computer.) 

1)  Exception  Report  -  The  IRTU  sends  the  host  computer  data 
concerning  only  those  points  which  have  changed  since  the 
last  "poll"  of  the  remote. 

2)  All  Data  Report  -  The  IRTU  sends  the  host  computer  all 
data  concerning  all  points  in  the  IRTU. 

3)  Downline  Load  -  The  IRTU  accepts  a  message  from  the  host 
computer  containing  setpoints,  time  delays,  and  deadband 
to  substitute  for  default  values. 

4)  Special  Status  -  The  IRTU  sends  the  host  computer  a 
message  stating  whether  it  needs  to  send  an  Exception 
Report  or  an  All  Data  Report. 

The  communication  scheme  employed  is  designed  to  minimize  the 
time  which  elapses  between  host  CPU  updates  by  reducing  message 
lengths.  The  typical  message  length  will  be  only  25  -  50 

characters  long  and  will  report  only  those  items  which  have 
changed  since  the  last  message.  At  five  minute  intervals,  the 
host  requests  All  Data  Reports  from  each  IRTU  to  be  sure  that  all 
host  CPU  points  have  been  updated.  With  this  scheme  and  a  2400 
baud  communications  rate,  all  IRTUs  are  polled  within  a  10-second 
interval.  An  alarm  occurring  in  an  IRTU  will  usually  require  no 
more  than  one  to  two  seconds  to  be  printed  on  the  alarm  log  and  to 
appear  on  the  CRT. 

The  alarm  logging  feature  provides  a  first-out  feature  which 
"tags"  the  first  of  a  group  of  alarms  which  appear  virtually 
simutaneously .  The  first  alarm  of  a  group  will  be  noted  in  three 
ways, 

1)  The  indicator  associated  with  the  first  alarm  will  flash 
at  twice  the  rate  of  the  indicators  for  later  alarms, 

2)  Point  logs  on  the  CRT  will  denote  the  first  alarm  with  an 
asterisk  on  the  left  side  of  the  data  entry  for  that 
point. 

3)  Printed  logs  will  include  a  red  asterisk  in  the  same 
manner  as  CRT-presented  data. 

The  first-out  features  implemented  will  help  an  operator  to 
determine  the  event  which  initiated  a  sequence  of  alarms. 

Host  Computer  Hardware.  The  host  computer  consists  of  the 
following  major  components  as  shown  within  the  dashed  lines  in 
Figure  2. 

1)  Host  Computer  -  Digital  Equipment  Corporation  LSI-11/23 
with  128K  words  of  16  bit  memory  -  located  in  the  ERC. 

2)  CRT  Terminals  (2)  -  Intelligent  System  Corporation  8100G 
Color  Graphic  CRTs  with  keyboards  -  one  each  located  in 
the  ERC  and  LTC . 
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3)  Printers  (2)  -  Diablo  60cps  "daisywheel*  printers  -  one 

each  located  in  the  ERC  and  LTC. 

4)  Tape  Drives  (2)  -  Digital  Equipment  Corporation  TU-58 

Tape  Cartridge  Drives  -  located  in  the  ERC. 

The  host  computer  includes  the  CPU  and  memory  modules,  a 
bootstrap  ROM  module  with  two  communication  ports,  and  additional 
four-channel  serial  communications  modules  for  a  total  of  14 
serial  communication  ports.  No  non-DEC  modules  are  needed  in  the 
host  computer. 

Host  Computer  Software.  The  host  computer  software  is 
written  in  MACRO-11  assembly  language  and  operates  with  the 
Digital  Equipment  Corporation  real-time  executive,  RSX11S.  All 
software  assembly  was  performed  on  a  Digital  Equipment  Corporation 
PDP11-34  system.  The  software  is  subdivided  into  various  tasks  as 
listed  below. 

1)  CRT/Keyboard  Tasks 

a)  Command  Processor  -  processes  operator  input  from  the 
keyboard. 

b)  Real-Time  Page  Generator  -  displays  system  diagrams 
and  updates  values. 

c)  Static  Page  Generator  -  displays  tutorial  pages. 

d)  Efficiency  Page  Generator  -  displays  engine 
performance  data. 

2)  Clock  Based  Tasks 

a)  GM  Time  -  reads  the  bridge  located  master  clock. 

b)  GM  Time  1  -  compares  the  bridge  located  master  clock 
to  internal  computer  clock  and  automatically  corrects 
the  internal  clock. 

c)  Watch  -  schedules  other  tasks. 

d)  Control  -  starts-up,  causes  display  refresh  and 
automatic  logs. 

3)  Tape  Operations  Tasks 

a)  Save  -  saves  average  data. 

b)  Dump  -  recovers  average  data. 

c)  Data-Base  Save  -  saves  system  data-base  for  recall. 


4)  Data  Gathering  Tasks 

a)  Pump  -  acquires  pump  run  time. 
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b)  Scan  -  communicates  with  IRTUs  and  processes  alarms. 

c)  Krunch  -  updates  averaged  data. 

d)  Load  -  downline  loads  IRTU  data-base. 

5)  Logging  Tasks 

a)  CRT  Log  -  provides  text  logs  to  the  CRT. 

b)  Print  Log  -  provides  text  logs  to  the  printer. 

c)  Bell  Log  -  provides  bell  logging  to  the  printer  when 
initiated  by  operator. 

The  software  includes  a  "Help"  page  to  provide  new  operators 
with  operating  instructions  and  allows  the  more  experienced 
operator  access  to  the  RSXllS  operating  system.  The  host  system 
is  designed  to  support  a  third  CRT  located  in  the  engineers' 
quarters.  During  periods  of  unattended  machinery  space 

operations,  the  system  can  be  configured  to  "redirect"  one  of  the 
CRT  tasks  to  operate  using  a  remote  terminal  located  in  the 
engineers'  quarters.  It  will  thus  be  possible  to  monitor 
machinery  plant  conditions  without  leaving  the  quarters. 


POWER  DISTRIBUTION  SYSTEM 
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Power  Distribution 

The  power  distribution  system  for  the  system  has  been 
designed  to  provide  the  following  features  to  ensure  a  reliable 
power  system. 

1)  Automatic  bus  transfer  upon  failure  of  the  primary  AC 
source. 

2)  No-break  power  for  30-minute  operation  if  all  AC  sources 
fail  using  static  UPS  (uninterruptible  power  source)  with 
batteries . 

3)  Automatic  switching  to  bypass  the  UPS  in  case  of  UPS 
failure. 

4)  Multiple  DC  supplies,  sized  so  that  failure  of  any  two 
will  not  disable  the  system. 

5)  Alarms  to  notify  the  operator  of  failure  of  any  single  DC 
supply . 

6)  DC  circuit  breakers  on  all  console  subsystems. 

Figure  8  illustrates  the  system  as  designed.  The  DC  supplies 
selected  are  the  fer ro-resonant  type  which  we  believe  to  be  the 
most  reliable  type  of  regulating  supplies  available.  These 
supplies  provide  adequate  regulation  and  can  be  short-circuited 
indefinitely  without  damage. 

Ballast  Heeling  System  Controls 

IRTU  6  (in  the  LTC)  includes  a  control  system  designed  to 
provide  automatic  ballasting  during  in-port  cargo  handling 
operations.  Dual  list  sensors  are  mounted  within  the  console  and 
are  used  to  sense  list  angle.  The  software  within  the  system 
checks  ballast  (wing)  tank  levels  and  will  automatically  align 
valves  before  starting  the  6000  GPM  Ballast/Heeling  pump.  The 
system  is  capable  of  aligning  valves  for  tank-to-tank , 
tank-to-sea,  and  sea-to-tank  pumping  conditions. 

The  system  includes  numerous  event  completion  checks  to 
verify  that  valves  have  reached  specified  states  within  allowable 
times,  that  pump  discharge  pressure  is  present,  and  that  list 
correction  is  actually  occurring.  Failure  to  meet  any  of  these 
conditions  will  result  in  pump  shutdown:  valves  will  be  commanded 
to  close,  and  the  system  will  return  to  manual  control.  An  alarm 
signals  the  operator  that  a  system  failure  has  occurred.  In 
addition,  the  operator  may  take  manual  control  at  any  time. 

The  software  for  this  system  includes  a  feature  to  allow  easy 
modification  of  timeout  intervals  and  pressure  limits  during 
trials.  Although  default  values  are  stored  in  ROM,  these  values 
are  transferred  to  RAM  during  system  operation  and,  consequently, 
can  be  modified  using  the  IRTU  maintenance  panel. 
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Pump  Controls 

Dual  pump  systems  are  provided  with  standby  controls  which 
will  automatically  start  the  off-line  pump  if  discharge  pressure 
falls  below  preset  minimums.  "RUN",  "STBY",  and  "STOP"  controls 
are  provided  for  each  pump  of  a  pair.  The  "RUN"  pushbutton  will 
provide  a  momentary  contact  closure  to  the  motor  controller  and 
will  enable  the  "STBY"  relay  of  the  other  pump.  The  "STBY" 
pushbutton  will  stop  the  pump  if  it  is  already  running,  energize 
the  "STBY"  relay,  and  disable  the  "STBY"  circuit  of  the  other 
pump.  Only  one  pump  can  be  in  the  standby  condition.  The  "STOP" 
pushbutton  breaks  the  holding  circuit  in  the  motor  controller  and 
removes  both  pumps  from  the  standby  mode. 

If  both  pumps  are  stopped,  depressing  the  "STBY"  pushbutton 
of  one  of  the  pumps  will  generate  a  run  contact  to  that  pump  after 
a  30-second  delay. 

If  a  pump  is  running  and  the  other  pump  is  in  standby, 
stopping  the  running  pump  (using  "STOP"  pushbutton)  will  also 
remove  the  standby  pump  from  "STBY",  thereby  preventing  it  _rom 
starting  when  the  stopped  pump  loses  discharge  pressure.  However, 
stopping  a  running  pump  locally  at  the  motor  controller  will  not 
prevent  the  "STBY"  pump  from  starting.  This  feature  is  only 
functional  from  the  console. 

The  "FAIL"  contact  from  the  motor  controller  causes  an 
audible  alarm.  The  "STOP"  indicating  pushbutton  will  flash  until 
the  alarm  is  acknowledged. 


APL  MACHINERY  SPACE  CONSOLES 
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PANEL  ARRANGEMENTS 


The  panel  arrangement  generally  follows  the  pattern  of  having 
operating  controls  placed  on  the  lower  (near  horizontal)  surface 
with  alarms,  meters,  and  demand  displays  placed  on  the  upper  (near 
vertical)  surface. 

Engine  Room  Console 

Engine  controls  and  monitoring,  generator  monitoring,  and 
other  propulsion  auxiliaries  are  located  in  the  ERC.  The  Sulzer 
throttle  control  is  placed  in  the  center  of  the  console  as  shown 
in  Figure  9,  All  engine  temperatures  are  monitored  via  the  engine 
mimic  to  the  immediate  left  of  the  throttle  control  section.  The 
CRT  is  placed  to  the  immediate  right  of  the  throttle  control  to 
allow  the  operator  quick  access  to  system  displays  and  data 
without  having  to  walk  to  the  end  of  the  console.  The  operator 
may  also  request  system  displays  concerning  ballast  tank/fuel  oil 
tank  levels  without  needing  to  go  to  the  LTC. 

Liquid  Transfer  Console 

Fuel  oil,  diesel  oil,  and  ballast  tank  levels,  and  associated 
pumps  and  valves  are  monitored  in  the  LTC.  This  console  includes 
a  mimic  arrangement  with  the  ballast  tank  system  located  on  the 
upper  surfaces  and  the  fuel  systems  located  on  the  lower  surfaces. 
Fuel  oil  and  diesel  oil  tank  level  monitoring  include  operator 
corrections  fos  fuel  specific  gravity  and  operator  variable  level 
setpoints  for  ease  c».  operation  during  pumping. 

Alarm  indicatoro  are  placed  in  several  locations,  depending 
on  the  type  of  input  device.  Alarms  associated  with  devices  with 
continuous  analog  displays  (meters)  have  alarm  indicators  placed 
above  and  below  the  meters.  Alarms  associated  with  contact  inputs 
are  generally  placed  in  rectangular  arrays  with  grouping  by 
function.  Alarms  associated  with  demand  displays  are  indicated 
within  the  pushbutton  used  to  initiate  the  display. 

PACKAGING 

The  consoles  are  constructed  of  11-gage  mild  steel  without 
internal  framing.  They  are  in  modular  sections,  with  each  section 
37.25  inches  (95  cm)  long,  mounted  on  a  structural  channel  base, 
to  provide  toe  space.  The  assembled  consoles  may  be  either  bolted 
or  welded  in  place. 

Cooling  is  provided  by  fans  mounted  in  the  ends  of  the 
console  arranged  to  intake  through  filters  at  the  fans  and  exhaust 
through  rear  door  louvers.  Fans  are  used  on  non-vital  system 
module  racks  to  avoid  local  hotspots?  vital  system  racks  require 
no  fans. 

Lockout  arms  are  provided  for  front  and  rear  doors  and 
console  front  panels?  panels  are  hinged  for  access. 
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SYSTEM  EVOLUTION 

The  system  supplied  for  the  container ships  is  interesting  in 
an  historical  sense  because  of  the  somewhat  parallel  development 
of  oil  and  gas  pipeline  supervisory  systems.  Pipeline  supervisory 
systems  have  evolved  in  four  stages  as  described  below: 

1)  Local  remote  controls  at  pumping  stations  -  coordination 
by  telephone;  manual  backup. 

2)  Central  controls  center  -  console  mounted  pushbuttons, 
indicators  and  meters;  automated  logging.  Local  remote 
backup/manual  backup, 

3)  Central  controls  center  -  console  plus  CRT  controls. 
Computer  does  logging,  batch  tracking,  leak  detection. 
Local  remote  backup/manual  backup. 

4)  Central  controls  center  -  multiple  CRT  only;  all 

functions  through  computer.  Backup  computer 

automatically  takes  over,  if  necessary.  Local  remote 
backup/manual  backup. 

It  appears  that  current  marine  systems  have  evolved  to  a 
state  between  the  second  and  third  stages  described  above.  The 
obvious  question  is:  should  shipboard  systems  proceed  to  the 
multiple-redundant  computer  systems  already  in  use  in  critical 
land-based  applications?  I  would  assume  that  reduced  manning, 
plus  the  need  to  closely  monitor  fuel  consumption,  will  lead  to 
the  use  of  such  systems,  possibly  in  combination  with  direct 
gaging  for  back-up. 
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SH INPADS 

AN  INTEGRATION  PHILOSOPHY  FOR  THE  21$T  CENTURY 

Cdr  James  E  Ironside 
Canadian  Navy 


ABSTRACT 

SHINPADS,  the  SHips  INtegrated  Processing  And  Display  System,  is  an 
integration  approach  to  the  total  ship  system  which  makes  use  of  current  trends 
in  embedding  intelligence  (computers)  in  almost  all  elements  of  a  ship  to  achieve 
an  integration  of  these  elements  which  is  simple,  fault  tolerant,  capable, 
flexible  and  supportable.  A  distributed  architecture  using  redundant  data  buses 
as  the  inter-element  communications  medium  between  intelligent  devices  provides 
capabilities  not  previously  possible.  Although  the  bus  can  connect  any 
intelligent  devices,  both  supportabil ity  and  the  ability  to  reconfigure  around 
damage  are  enhanced  by  a  comprehensive  set  of  standardized  digital  processing 
elements  and  displays.  All  elements  necessary  to  construct  a  SHINPADS  system 
are  either  in  production  or  in  late  stages  of  development. 

THE  PROBLEM  OF  SHIP  INTEGRATION 

Of  all  the  problems  facing  the  designers  of  naval  ships,  none  strikes  more 
fear,  none  has  more  risk,  none  takes  longer,  and  none  has  more  problems,  than 
ship  system  integration.  There  is  complexity  beyond  comprehension  in  the 
thousands  of  wires  and  interconnections  between  various  systems.  Costs  are 
measured  in  dollars  per  metre  of  wire,  and  more  metres  mean  more  dollars.  Design 
changes  because  of  faults  mean  yet  more  installation  work  and  more  dollars.  Even 
when  it  has  been  put  together  and  set  to  work,  it  is  still  not  satisfactory.  It 
is  vulnerable  because  it  is  impossible  to  replicate  this  mass  of  cabling.  There 
are  many  points  of  failure  where  large  portions  of  the  ship  system  can  be  disabled. 
It  is  not  particularly  capable,  as  subsystems  are  unable  to  use  information  which 
would  be  valuable  to  them  because  they  are  not  connected.  They  are  unable  to 
overcome  faults  by  bypassing  breakdowns.  They  are  unable  to  use  all  of  the 
ship's  resources  in  their  task.  The  systems  are  inflexible.  Most  so-called 
integration  is  not  integration  at  all,  but  merely  a  collection  of  minor  empires. 
Components  are  pathologically  bound  to  each  other  in  the  system  without  standard 
interfaces  and  thus  changes  must  be  massive  and  expensive,  and  thus  changes  are 
not  done.  Furthermore  the  equipments  are  close  to  unsupportable .  Each  peculiar 
equipment  demands  its  own  special  technicians,  unique  training,  unique  spares, 
and  peculiar  shore  support. 

If  we  could  start  from  scratch,  what  would  we  ask  for  for  ship  integration? 

a.  Simplicity.  The  system  should  use  standard  components  and  interfaces 
wherever  possible  to  minimize  unique  types  of  equipment.  It  should 
use  the  minimum  number  of  components  and  wires.  The  user  should  have 
little  concern  with  the  mechanisms  of  integration. 

b.  Low  Cost.  It  would  be  nice  for  the  system  to  be  cheapest  on  a  first 
cost  basis.  It  is  essential  that  it  be  cheaper  on  a  life  cycle  basis. 

This  implies  reduction  of  cabling  for  first  cost  and  the  ability  to 
allow  equipment  change  without  massive  internal  wiring  change. 

c.  Redundancy.  The  integration  system  should  be  desiqned  such  that  no 
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single  point  of  failure  exists  in  the  system*  and,  if  possible, 
such  that  multiple  failures  will  not  cause  it  to  cease  operation. 

d.  Capacity.  The  system  should  be  able  to  handle  not  only  the 
initial  requirements  of  the  ship  system,  but  should  have  sufficient 
reserve  capacity  to  allow  upgrading  of  the  equipments  and  systems 
over  the  life  time  of  the  ship  without  requiring  a  new  integration 
method. 

e.  Flexibility.  The  system  should  impose  no  restrictions  upon  the 
Command's  use  of  the  operational  equipments. 

f.  Supportabilitv.  The  system  should  minimize  requirements  for 
training,  for  technical  support,  and  for  shore  infrastructure. 

SHINPADS 

SHINPADS  is  an  architectural  concept  that  satisfies  these  requirements.  The 
ship  is  one  system,  from  engines  to  guns  not  just  a  collection  of  independent 
subsystems.  Subsystem  elements  are  functions  to  be  done,  not  tightly  bound 
collections  of  single  purpose  parts.  Systems  are  composed  of  intelligent 
processes  communicating  with  each  other,  not  a  central  intelligence  giving  orders 
to  dumb  peripherals.  The  ship  is  optimized  as  a  total  combat  unit.  Given  this 
philosophical  viewpoint,  it  is  possible  to  structure  a  system  to  achieve 
simplicity,  redundancy,  capacity,  flexibility,  and  supportabi 1 i ty,  in  an 
economic  fashion. 

PRINCIPLES  OF  SHINPADS 

SHINPADS  can  be  described  in  terms  of  three  fundamental  concepts. 


Figure  1  SHINPADS  Architecture 
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a.  A  Distributed  System.  A  SH INPADS  system  is  distributed  in 
geography,  in  function,  and  in  control.  Only  in  this  way  is 
it  practical  to  achieve  relative  invulnerability  to  single 
point  failures,  whether  these  failures  are  “normal"  or  combat 
caused  damage. 

b.  A  Data  Bus  Structure  Interconnecting  Intelligent  Devices.  By 
giving  all  devices  access  to  all  of  the  ship's  information,  it 
is  possible  to  achieve  redundancy  of  function  and  sharing  of 
work  in  the  face  of  changing  battle  needs.  It  is  possible  to 
upgrade  systems,  either  by  improvement  of  individual  components 
or  by  replacement  and  addition  of  new  components,  without  massive 
wire  changes. 

c.  Standardization  in  Hardware  and  Software.  Only  through  standards 
can  we  manage  the  escalating  problems  of  designing,  building, 
inte  grating,  and  maintaining  combat  systems.  Only  through 
standardization  can  we  support  the  systems  through  their  lives, 
by  avoiding  needless  multiplication  of  technicans,  training, 
spares,  and  support  facilities. 

SHINPADS  is  a  ship  level  optimization.  For  new  equipment,  the  SHINPADS 
concept  can  be  incorporated  from  the  outset  and  in  fact  can  result  in 
simplification  of  development  by  reducing  the  scope  of  equipment  that  must  be 
developed.  In  the  transition  from  the  older  philosophies,  SHINPADS  allows  a  mix 
of  old  and  new  equipment  at  a  relatively  small  development  cost  for  interfaces 
between  old  equipments  and  SHINPADS,  SHINPADS  may  not  always  be  locally 
optimal  in  the  sense  of  indulging  individual  equipment  and  archi tectural 
preferences,  but  neither  are  specifications  or  standards.  The  SHINPADS  concept 
is  necessary  if  we  wish  to  keep  a  capable  navy  at  sea  in  the  future. 

HOW  SHINPADS  WORKS 

The  SHINPADS  data  ubusu  consists  of  two  triaxial  cables  connecting  all 
systems  on  the  ship,  carrying  serial  digital  data  at  a  ten  megabit  per  second 
rate.  One  of  these  cables  carries  out  a  polling  function  to  determine  the  users 
who  wish  to  send  messages  on  the  bus.  The  second  cable  carries  data.  Polling 
goes  on  while  data  is  being  transmitted,  and  thus  the  full  capacity  of  the  cable 
is  available  for  data. 

Intelligent  User  Connection 

Intelligent  users  connect  to  the  bus  via  a  Bus  Access  Module  (BAM)  and  a 
node.  The  BAM  consists  of  a  passive  tap  to  the  bus  cable,  one  card  and  a  self 
contained  power  supply.  The  taps,  because  they  contain  only  a  few  passive 
components,  are  very  reliable.  Each  BAM  contains  amplifiers  which  can  put 
signals  onto  the  bus  cable,  and  which  regenerate  the  received  bus  signal  and 
pass  it  on  to  up  to  4  nodes. 

The  basic  node  is  a  set  of  six  cards,  For  transmission,  it  passes  messages 
from  the  user  to  the  BAM  and  onto  the  bus.  For  reception,  it  screens  messages 
from  the  bus  for  those  the  user  has  declared  an  interest  in,  and  passes  these  on. 
This  message  screening  is  an  essential  function  to  prevent  the  user  from  the 
overhead  of  examining  all  bus  message  traffic.  The  node  handles  all  the  bus 
management  functions  for  the  user  so  that  the  user  need  not  know  any  protocols 
at  this  level.  The  node  hardware  interface  is  either  NATO  serial  interface 
STANAG  4153  or  a  NATO  parallel  interface  STANAG  4146. 
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Figure  2  Basic  SHINPADS  Bus 

The  user,  a  computer  of  some  sort,  sees  a  standard  NATO  interface,  and  if 
he  is  a  UYK  20,  502  or  505  he  sees  at  an  application  program  level  a  standard 
computer  executive  which  provides  him  among  other  functions  a  handler  for 
sending  and  receiving  messages  on  the  bus.  He  is  able  to  send  messages  at  four 
levels  of  priority  to  either  specific  receivers  or  to  groups  of  receivers  in  a 
true  broadcast  mode-  He  may  address  his  messages  by  either  physical  addresses 
(ie,  node  number  7)  or  by  .message  content  addresses  (ie, Navigation  Data).  He  can 
receive  messages  either  addressed  specifically  to  him  or  broadcast  ,  but 
he  receives  only  the  messages  he  has  declared  he  wishes  to  see.  His 

own  address  can  also  be  logical  or  physical.  There  is  nothing  in  the  hardware 
that  predetermines  who  he  is  or  what  he  is  doing. 

Dumb  Data  Transmission 

Fast  dumb  data  is  typically  display  information  which  comes  from  a  sensor 
directly  to  a  display.  This  data  may  be  in  many  different  formats:  radar  PPI 
or  A-Scan,  TV  formats,  or  random  points.  In  order  to  achieve  the  aims  of 
SHINPADS,  it  is  necessary  to  have  an  intelligent  display  which  can  handle  any 
sensor.  We  have  developed  such  a  display  at  Computing  Devices  in  Ottawa, 

The  SHINPADS  Standard  Display  (SSD)  can  handle  any  type  of  radar;  framing 
sensors  such  as  FUR  or  TV;  line  scan  sensors  such  as  Sonar  or  Infra  Red;  or 
direct  writing  using  any  of  several  user-selectable  patterns  into  its  four 
million  bit  video  memory.  The  display  is  normally  interfaced  to  a  microcomputer 
which  handles  local  operator  and  tactical  functions,  and  which  communicates 
with  other  systems  through  the  data  bus.  The  display  includes  a  graphics 
package  and  full  NTDS  symbology.  Sensors  are  connected  to  the  display  through 
one  or  more  switchboards  which  allows  any  display  to  view  any  sensor  and  thus 
provides  the  required  flexibility  and  redundancy. 

Low  data  rate  dumb  data  is  most  reasonably  handled  by  providing  area 
concentrators  throughout  the  ship  to  accept  dumb  information  in  the  form  in 
which  it  is  produced,  and  convert  it  to  bus  format.  The  concentrator  would  be 
a  small  standard  micro  computer.  Examples  of  dumb  data  are  wind  speed,  wind 
direction,  ship  speed,  compartment  flooding  indicators,  etc. 

D2  2-4 


TYPICAL  SCENARIO 

Consider  a  typical  scenario  when  an  operator  at  sea  detects  a  potential 
target.  The  commanding  officer  and  the  operations  officer  would  command  their 
displays  to  select  the  sensor  which  had  detected  the  target.  The  display  would 
pass  this  command  the  bus  to  the  switchboards) ,  and  the  switchboard  would 
connect  the  appropriate  video  to  the  displays.  The  captain  would  tell  the 
operator  to  change  the  mode  of  the  sensor.  The  operator,  through  his  display 
and  the  bus,  would  send  the  appropriate  orders  to  the  sensor  to  change  the  mode. 
A  separate  processor  on  the  bus,  the  Threat  Evaluation  and  Warning  processor, 
woula  assess  the  danger  this  target  (which  is  stored  in  the  Track  File 
Management  processor)  posed  the  ship,  and  would  notify  the  cotnnand.  The 
captain  would  order  a  weapon  assigned  to  the  target.  The  operations  officer 
instructs  the  Fire  Control  computer  to  compute  a  solution  on  the  indicated 
target.  The  Fire  Control  computer  would  pass  the  results  of  its  calculation  on 
to  the  Weapon  Control  processor  at  the  weapon.  Steering  and  engine  orders  would 
be  passed  on  the  bus  to  the  micro-processors  controlling  the  rudder  and 
machinery.  The  captain,  from  his  display,  would  give  the  order  to  fire  which 
would  be  passed  via  the  bus  to  the  Weapon  Control  processor  and  fire  the 
weapon . 

Nothing  in  this  scenario  presupposes  which  sensor  or  which  weapon  will  be 
used.  All  data  is  available,  and  there  is  nothing  in  the  hardware  to  prevent 
(for  example)  the  ASROC  from  being  assigned  to  a  sea  plane.  If  checks  and 
restrictions  are  to  be  imposed,  these  restrictions  will  be  included  in  the 
system  software  according  to  the  current  tactical  doctrine  and  not 
pathologically  bound  into  the  wiring  of  the  system. 

REDUNDANCY  AND  FAULT  TOLERANCE 

Cach  node  can  connect  to  up  to  6  bus  cables,  only  two  of  which 
are  required  for  full  data  communication.  There  is  no  pre-assignment  of 
function,  and  any  cable  can  be  used  for  either  polling  or  data  transmission. 
Furthermore,  the  cables  can  be  geographically  distributed  in  the  ship  to  ensure 
that  there  is  no  concentration  where  a  single  combat  casualty  could  knock  out 
all  of  them.  Thus,  at  least  five  cables  of  the  six  must  fail  before  the  system 
will  be  down.  Cable  reconfiguration  is  done  without  effect  on  the  user. 
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Any  node  can  be  a  bus  controller  by  the  addition  of  one  card.  Thus  there 
are  as  many  alternate  bus  controllers  as  required  by  the  system  designer.  If 
the  primary  bus  controller  ceases  to  operate  for  any  reason,  an  alternate  will 
automatically  pick  up  the  task  and  re-establish  the  polling  sequence;  if  this 
also  fails,  another  will  pick  up;  and  so  on  to  the  limit  of  bus  controller 
nodes.  Controller  changes  are  also  invisible  to  the  users. 


Figure  6  Bus  Controller  Redundancy 


Nothing  in  the  processors  distinguishes  them  functionally  from  each  other 
except  the  software  they  are  running.  Thus,  should  a  processor  fail  -  for 
example,  our  fire  control  processor  in  the  typical  scenario  -  then  another 
processor  can  load  in  the  fire  control  software  over  the  bus  and  pick  up  the 
function.  There  are  as  many  backups  for  a  processor  in  the  system  as  there 
are  processors  in  the  system;  the  least  important  task,  whether  defined  in  a 
pre-arranged  sequence  or  by  operator  input,  can  always  be  shed  to  take  on  a 
more  important  task. 

Beciuse  any  display  can  present  any  sensor  through  the  duplicated 
switchboards,  failure  of  a  display  is  not  the  catastrophy  it  once  was.  Every 
display  is  a  spare  for  every  other;  capability  is  degraded  but  in  a  graceful 
fashion. 

Only  the  leaves  of  the  system,  that  is  the  sensors  and  weapons  themselves, 
cannot  be  bypassed  in  case  of  a  fault.  Only  duplication  of  the  sensors  and 
weapons  can  provide  redundancy  at  this  level.  All  other  components  in  the 
integration  system  can  suffer  multiple  faults  and  still  continue  to  function. 

SH INPADS  STATUS  IN  FALL  1981 

Standardization 

We  have  established  within  the  Navy  a  policy  on  standardization  which 
requires  the  use  of  certain  specified  digital  units  in  all  development  and 
production  projects.  Presently  7isted  components  include  the  AN/UYk-505 
mini  computer,  the  AN/UYK-502  micro  computer,  the  AN/USH-26  cassette  tape 
drive  and  the  AN/UYQ-69  alphanumeric  display.  The  AN/UYK-505  is  the  extended 
memory  version  of  the  Sperry  AN/UYK-20  and  is  in  production.  The  AN/UYK-502 
micro  computer  was  developed  by  DND  and  Sperry  Uni  vac  as  a  software  compatible 
"low  end"  version  of  the  AN/UYK-20  instruction  set  architecture  for  use  in 
distributing  intelligence  throughout  the  ship,  and  is  now  in  production  in 
Winnipeg.  The  display  and  tape  drive  are  USN  standards.  The  USN  standard 
software  executive,  SDE.X,  is  also  our  standard  as  is  the  CMS-2M  compiler  and 
the  MTASS  program  support  software  which  we  have  in  a  multi  user  program 
generation  center  in  Halifax. 
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Reaching  standardization  status  are  the  SH1NPADS  Standard  Display,  now  at 
EDM  contract  at  Computing  Devices  in  Ottawa,  and  the  data  bus  Node,  also  at 
EDM  contract  at  Sperry  Univac  in  Minneapolis.  The  data  bus  nodes  will  also 
be  produced  in  Winnipeg.  The  Bus  Access  Module  is  being  Drought  to  production 
status  by  Sperry  Univac  in  Minneapolis  using  internal  research  and  development 
funds . 

Standard  digital  equipment  is  being  specified  in  current  contracts  for 
electronic  warfare,  machinery  control,  message  handling,  active  and  passive 
sonar  developments,  variable  depth  sonar  towing  monitor  systems,  submarine 
fire  control  systems,  and  many  smaller  development  projects. 

Bus  Structure 

The  SHINPADS  data  bus  was  first  demonstrated  in  ADM  form  in  the  fall  of 
1979  using  6  nodes,  32  BAMs,  and  3  cables  at  Sperry  Univac  in  Minneapolis. 

It  has  travelled  widely  to  subsequent  demonstrations  in  Weisbaden  Germany, 
and  to  Japan,  and  is  currently  in  a  3  node/3  cable  form  in  the  Sperry  plant 
here  in  Ottawa.  The  EDM  system  is  now  being  set  to  work  in  Sperry  Univac  in 
Minneapolis. 

SUMMARY 

SHINPADS  is  an  architecture  and  integration  concept  which  can  provide 
functions  for  future  ship  systems  which  are  simple,  capable,  flexible, 
supportable,  and  survivable  at  reasonable  cost.  Necessary  components  for 
the  system  are  either  in  production  or  are  at  contract  for  the  last  stage 
before  production.  There  is  strong  international  interest  but  so  far  other 
nations  are  still  in  a  catchup  situation.  SHINPADS  is  ready  to  be  designed 
into  systems  now. 
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ABSTRACT 

The  Shipboard  Data  Multiplex  System  (SDMS)  is  a  general-purpose  information 
transfer  system  directed  toward  fulfilling  the  internal  data  intercommunication 
requirements  of  a  variety  of  naval  combatant  ships  and  submarines  in  the  19801990 
time  frame.  The  need  for  a  modern  data  transfer  system  of  the  size  and  capability 
of  SDMS  has  increased  in  unison  with  the  sophistication  of  shipboard  electrode 
equipment  and  the  associated  magnitude  of  equipment -to-equipme nt  signal  traffic. 

Instead  of  miles  of  unique  cabling  that  must  be  specifically  designed  for  each 
ship,  SDMS  will  meet  information  transfer  needs  with  general-purpose  multiplex 
cable  that  will  be  installed  according  to  a  standard  plan  that  does  not  vary  with 
changes  to  the  ship's  electronics  suite.  Perhaps  the  greatest  impact  of  SDMS  will 
be  the  decoupling  of  ship  subsystems  from  each  other  and  from  the  ship.  Standard 
multiplex  interfaces  will  avoid  the  cost  and  del  iy  of  modifying  subsystems  to  make 
them  compatible.  The  ability  to  wire  a  new  ship  according  to  a  standard  multiplex 
cable  plan,  long  before  the  ship  subsystems  are  fully  defined,  will  free  both  the 
ship  and  the  subsystems  to  develop  at  their  own  pace,  will  allow  compression  of  the 
development  schedules,  and  will  provide  ships  with  more  advanced  subsystems. 

This  paper  describes  V  e  SDMS  system  as  it  is  currently  being  developed  in  the 
Engineering  Development  stage  by  the  IK  S,  Navy.  The  results  of  preliminary  design 
studies  on  the  DDC  47  Class  and  SSN  submarine  platforms  are  also  presented. 

INTRODUCTION 

The  ultimate  use  of  SDMS  on  any  particular  Navy  ship  or  submarine  platform 
depends  upon:  (1)  successful  demonstration  of  the  operational  effectiveness  and 
suitability  of  SDMS  through  shipboard  Technical  and  Operational  Evaluation 
(TECHEVAL/OPEVAL);  (2)  establishment  of  a  baseline  SDMS  conf igurut ion  for  each  hull 
class  and  then  preparation  of  detailed  implementation  plans;  (3j  performance  of 
land-based  integration  tests  unique  to  the  particular  platform.  Upon  completion  of 
these,  a  determination  will  be  made  to  introduce  SDMS  in*o  specific  classes.  The 
TECHEVAL/OPEVAL  considerations  are  being  addressed  as  part  of  the  basic  SDMS  engi¬ 
neering  developmental  program.  The  following  dissertation  concentrates  on  the 
platform  application  studies. 

In  1979  the  Navy  completed  preliminary  SDMS  design  applications  studies  on  two 
platforms:  PDG  47  Class  ships  and  future  Attack  Submat ine  (SSNs).  These  studies 
were  conducted  in  parallel  with  the  design  of  the  SDMf  Engineering  Development 
Models  (SDMS-EDM).  Factors  unique  to  eai  h  platf<  rm  studied  dictated  different 
approaches  f>r  incorporating  SDMS. 

The  study  of  DDG  47  Class  ships  resulted  in  a  definition  of  the  hardwired  cir¬ 
cuits  that  could  be  replaced  with  SDMS,  This  study  not  only  xami nod  the  replace¬ 
ment  of  conventional  wiring  hut  also  the  elimination  of  -ertain  switchboards  and 


signal  data  converters.  As  a  practical  matter,  the  DDG  47  application  study  was 
conducted  on  a  "bot tom-up"  basis  (fitting  SDMS  into  the  existing  designs). 

The  other  SDMS  application  study  developed  a  preliminary  design  applicable  to 
future  Attack  Submarines  (SSNs)  and  FY8«.  SSN  in  particular.  Here  a  "top-down" 
approach  was  used.  In  this  approach  SDMS  was  used  as  a  system  integration  medium 
to  achieve  the  integration  of  advanced  displays,  interior  communications,  naviga¬ 
tion,  and  selected  combat  system  elements  into  an  efficient  and  effective  system. 
Since  space  and  weight  savings  were  of  primary  importance,  the  system  design 
demanded:  (1)  that  the  packaging  of  SDMS  be  tailored  to  space  allocated,  and  (2) 

that  selected  data  conversion  functions  be  provided  by  special  purpose  SDMS 
Input /Output  Modules  (IOMs). 

These  and  other  forthcoming  application  studies,  together  with  the  basic  SDMS 
Development  Program,  will  provide  the  basis  for  an  SDMS  implementation  program 
which  the  U.  S.  Navy  can  support  with  high  confidence. 

SHIPBOARD  DATA  MULTIPLEX  SYSTF  .SDMS)  DESCRIPTION 

The  Shipboard  Data  Multiplex  System  (SDMS)  is  a  modular,  general-purpose 
multiplex  system  capable  of  transferring  the  majority  of  internal  data  intercom¬ 
munication  signals  wherever  needed  aboard  ship.  Instead  of  miles  of  unique  cabling 
that  "ust  be  specifically  designed  for  each  ship,  SDMS  will  meet  present  and  future 
Information  transfer  needs  with  general-purpose  multiplex  cables  that  will  be 
installed  according  to  a  standard  plan  that  does  not  vary  with  changes  to  the 
ship's  electronics  configuration.  SDMS,  as  a  data  transfer  system,  will  serve  to 
interconnect  a  wide  variety  of  shipboard  systems  and  equipment  such  as:  weapon 

direction  systems,  command  and  control  systems,  combat  information  centers,  damage 
control  centers,  navigation  equipment,  displays,  propulsion  and  electrical 
machinery  control  devices,  and  electrical  power  distribution  control. 

System  Architecture 

The  design  of  SDMS  is  modular  to  meet  the  level  of  redundancy  and  total  infor¬ 
mation  transfer  bandwidth  requirements  of  a  wide  variety  of  platforms  whether  it  be 
a  frigate,  an  aircraft  carrier,  a  submarine  or  a  shore  test  facility.  The  modular 
building  blocks  are  multiplex  buses,  Traffic  Controllers  (TCs),  Area  Multiplexers 
(AMs),  Remote  Muitiplexers  (RMs),  Area  Remote  Multiplexers  (ARMs),  and  Input /Output 
Units  (IOUs).  Figures  1  through  4  are  functional  block  diagrams  showing  various 
SDMS  architectures. 

The  dual  stage,  five  primary  bus  configuration  shown  in  Figure  1  is  intended 
to  be  modularly  expandable  to  handle  the  largest  ship  platforms.  Figure  2  shows 
the  single  stage,  three  primary  bus  configuration  which  will  provide  a  great  deal 
of  versatility  in  the  smaller  ship  platforms.  Figure  3  shows  the  basic  dual  stage 
system  with  single  stage  (e.g.,  ARMs)  judiciously  used  where  low-density  transfers 
are  required.  Another  aspect  of  SDMS's  flexibility  is  shown  in  Figure  4,  in  which 
primary  buses  1  and  2  are  essentially  dedicated  to  the  subsystems  communicating 
through  the  ARMs  although  they  also  have  the  ability  to  communicate  with  all  other 
user  systems  via  their  connections  to  primary  buses  3  and  4. 

SDMS  provides  for  interchange  of  information  between  AMs  by  both  time  division 
and  frequency  division  multiplexing  over  a  fivefold  redundant  data  bus,  under  the 
control  of  Traffic  Controllers.  Each  of  the  5  primary  cables  has  3  carrier 
frequencies  for  a  total  of  25  channels.  Twenty  of  these  channels  are  used  for 
message  transfer  between  AMs.  The  remaining  five  channels  are  assigned  one  each  to 
the  five  Traffic  Controllers.  One  Traffic  Controller  is  connected  to  each  primary 
cable.  In  large  systems,  up  to  16  dual-redundant  Area  Multiplexers  (AMs)  and  up  to 
2  Maintenance  Units  (MUs)  shall  be  connected  to  each  of  the  primary  buses,  and  up 
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Figure  1.  SDMS  Architecture:  Dual  Stage. 


Figure  3.  SDMS  Architecture:  Hybrid  Configuration. 


Figure  4.  SDMS  Architecture:  Hybrid/Dedicated. 


to  112  dual  redundant  Remote  Multiplexers  (RMs)  shall  be  served  by  the  AMs.  Each 
RM  shall  directly  serve  up  to  four  Input/Output  Units  (lOUs).  Two  different  sizes 
of  10U  shall  be  provided  having  capacities  of  8  and  16  Input/Output  Modules  (IQMs), 
respectively.  In  smaller  systems,  up  to  32  ARMs  (16  dual-ARM  pairs)  and  1  MU  shall 
be  connected  to  each  of  the  primary  buses.  Each  ARM  shall  internally  accommodate 
up  to  four  IOMs  and  shall  directly  serve  up  to  three  external  IOUs. 

The  Input/Output  Units  serve  as  the  normal  user  access  point  to  SDMS,  and  are 
located  as  close  as  possible  to  user  subsystems. 

One  or  more  Remote  Multiplexers  will  normally  be  located  in  each  ship  compart¬ 
ment  that  contains  any  significant  quantity  of  signal  generating  or  receiving 
equipment.  The  Area  Multiplexers  will  be  located  in  interior  compartments  that  are 
central  to  high  densities  of  Remote  Multiplexers,  and  the  Traffic  Controllers  will 
be  distributed  among  several  interior  ship  compartments.  The  Area  Remote  Multi¬ 
plexer  (\RM)  basically  performs  the  functions  of  both  the  AM  and  RM.  It  can  be 
used  in  locations  where  signal  densities  do  not  merit  using  an  AM  and  RM  combina¬ 
tion.  A  Maintenance  Unit  (MU)  will  be  located  in  a  compartment  that  is  convenient 
to  Interior  Communications  (IC)  maintenance  personnel. 

System  Operation 

Figure  5  is  a  simplified  system  block  diagram  that  delineates  the  signal  path 
between  two  user  subsystems.  Suppose  User  Subsystem  B  has  requested  an  update  of 
the  interface  signals  from  User  Subsystem  4.  The  signals  are  first  coupled  into  a 
local  Input/Output  Unit,  then  to  the  Remote  Multiplexer,  shown  on  the  left,  th  ;t 
typically  would  be  located  somewhere  near  User  Subsystem  A.  The  Remote  Multiplexer 
would  assemble  samples  of  each  of  the  signals  from  User  Subsystem  A  along  with  any 
other  user  equipments  that  transmit  data  to  the  same  Remote  Multiplexer  at  the 
other  end  of  the  path,  and  forward  this  message  to  the  nearest  Area  Multiplexer 
shown  on  the  left.  The  Area  Multiplexer  will  translate  the  baseband  time -division- 
multiplexed  message  into  a  frequency  division-multiplexed  signal  on  jne  of  the  four 
data  channels  In  the  40-80MHz  band.^D  Access  to  one  of  the  five  primary  multi¬ 
plexed  buses  that  run  throughout  the  ship  is  controlled  by  a  separate  Traffic 


Figure  5.  SDMS  Signal  ^low 
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Controller  for  each  bus.  At  the  destination  the  message  from  User  Subsystem  A 
follows  the  reverse  path  to  reach  User  Subsystem  B.  It  is  picked  off  the  primary 
bus  by  the  nearest  available  Area  Multiplexer,  where  it  is  converted  back  to  a 
baseband  time-division-multiplexed  message  for  subsequent  distribution  to  the  users 
via  the  Remote  Multiplexer  and  Input/Output  Unit  nearest  User  Subsystem  B.  Note 
that  this  entire  process  occurs  essentially  in  real  time;  that  is,  SDMS  is  not  a 
store -and -forward  information  transfer  system.  As  each  subsystem  signal  is 
converted  from  its  original  analog,  synchro,  digital,  or  discrete  form,  it  is 
simultaneously  transmitted  in  time-di vision-mult iplex  form  through  the  Remote 
Multiplexer  and  in  the  frequency-division-multiplex  form  through  the  Area 
Multiplexer.  At  no  point  in  the  system  is  the  entire  message  stored  so  as  to  incur 
a  data  staleness  problem. 

System  Control  Mechanization 

SDMS  provides  an  unusual  approach  toward  its  control  mechanization  in  that  it 
is  totally  asynchronous  and  distributed.  Asynchronous  means  “free  running,”  or  not 
governed  by  a  central  clock.  The  asynchronous  distributed  control  approach  was 
chosen  after  a  thorough  analysis  of  both  the  technical  and  operational  requirements 
for  shipboard  information  transfer.  It  essentially  provides  the  ability:  (1)  to 
establish  a  data  exchange  path  between  user  subsystems  with  full  local  control  of 
information  transfer  parameters  such  as  message  length,  message  update  rate,  mes¬ 
sage  priority,  etc.,  and  (2)  to  make  changes  in  message  transfer  parameters  and  in 
system  interconnectivity  as  the  requirement  occurs,  with  low  cost,  with  simple 
field  verification,  and  without  the  possibility  of  degrading  or  disabling  the 
entire  ship  if  errors  are  made.  This  approach  also  allows  SDMS  to  efficiently 
handle  both  periodic  signals  and  aperiodic  events  like  alarms  which  randomly  occur 
once  an  hour,  once  a  day,  or  once  per  mission. 

Distributed  control  means  that  the  basic  control  mechanism  determining  what 
data  will  be  sent  at  what  time,  from  what  signal  source  to  what  signal  destination 
(sink),  is  not  located  in  a  central  device  but  is  distributed  through  the  system. 
No  software  is  used  in  the  control  of  SDMS.  Instead,  the  transfer  of  data  between 
two  subsystems  is  controlled  by  two  "plug-tn"  message  Programmable  Read-Only 
Memories  (PROMs) — one  in  the  SDMS  terminal  serving  the  source,  and  one  in  the  sink 
terminal.  The  coding  in  these  two  PROMs  controls  all  aspects  of  the  subsystem 
message  transfer/update  rate,  priority,  addressing,  etc.,  completely  independent 
from  all  other  messages  within  the  system.  To  establish  a  new  data  path  via  SDMS, 
one  simply  has  to  insert  appropriate  interface  cards  (input  and  output)  and  program 
the  PROMs  in  the  Remote  Multiplexers  located  nearest  the  transmitting  and  receiving 
equipments. 

User  Interface  to  SDMS 

The  IOU  provides  the  user  with  access  to  SDMS  via  signal  conditioning  circuits 
called  Input/Output  Modules  (IOMs).  TCUs  can  be  modularly  implemented  with  up  to  4 
boxes  capable  of  handling  a  maximum  total  of  64  input/output  modules  per  Remote 
Multiplexer. 

Input  or  output  modules  of  the  synchro,  digital  data,  analog,  or  discrete 
variety  can  be  separately  plugged  into  the  Input/Output  Unit  to  meet  the  signal 
distribution  requirements  of  the  user  subsystems  located  in  each  compartment.  The 
slots  into  which  the  Input/Output  Module  cards  are  inserted  are  not  dedicated. 
That  is,  any  mixture  of  synchro,  digital,  analog,  or  discrete  cards  can  be  inserted 
at  random  into  these  slots. 

The  Engineering  Development  Model  of  SDMS  provides  a  selection  of  Input/Output 
Modules  (IOMs).  These  IOMs  have  been  developed  for  the  purpose  of  converting 
signal  types  noted  in  existing  shipboard  electronic  equipments  into  a  standard 
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digital  format  that  is  required  for  transmission  within  SDMS.  However,  the  use  of 
these  modules  is  flexible  in  that  user  subsystem  signals  can  enter  SDMS  in  one 
format  and  exit  in  another,  if  desired.  Additional  modules  will  be  developed  as 
the  need  becomes  apparent* 

FY80  SSN  STUDY 

Approach 

The  FY80  SSN  preliminary  design  study  was  initiated  with  an  agreed  upon  set  of 
ground  rules  that  collectively  can  be  categorized  as  a  top-down  approach.  These 
ground  rules  were  developed  during  a  previous  conceptual  design  study  which 
addressed  where  SDMS  might  save  space,  improve  user  system  capability,  provide 
future  growth,  but  not  necessarily  provide  an  initial  cost  savings.  To  this  extent 
the  signals  to  be  multiplexed  and  guidelines  for  locating,  packaging,  and  main¬ 
taining  SDMS  hardware  were  provided  at  the  beginning  of  the  study.  Since  several 
parallel  studies  on  other  interfacing  subsystems  were  also  being  performed,  the 
full  integration  on  other  interfaces  was  encouraged.  The  Ship  Data  Display  Unit 
(SDDU)  and  the  Ship  Control  Panel  were  two  subsystems  of  particular  interest.  In 
addition,  the  elimination  of  subsystem  interfaces  which  required  the  use  of  400Hz 
power  was  considered. 

Results 

During  the  course  of  the  study  the  original  signal  list  was  slightly  modified, 
with  SDMS's  major  user  interfaces  being  with  the  Navigation,  Ship  Control,  and  Com¬ 
puter  Subsystems.  Examples  of  the  types  of  functions  transferred  are  ship's  speed 
and  depth  sensor  data  and  their  display;  ship's  heading,  pitch,  and  roll;  position 
of  submarine  control  surfaces;  and  cavitation  hydrophone  data.  The  SDMS  equipment 
complement  consisted  of: 

2  Traffic  Controllers  and  Primary  Buses 

6  Area/Remote  Multiplexers  (ARMs) 

7  Input/Output  Units  (4-  and  8-slot  types) 

32  Input/Output  Modules 

1  Maintenance  Unit 

In  order  to  meet  the  requirements  for  minimum  use  of  volume  and  deck  space, 
the  Traffic  Controllers,  the  Maintenance  Unit,  and  two  ARMs  were  packaged  into  a 
single  water-cooled  enclosure. ( In  addition,  two  ocher  ARMs  were  to  be  located 
in  the  Ship  Control  Panel  (SCP).  A  net  weight  saving  of  1.5  tons  and  85  cubic  feet 
of  volume  was  achieved  using  SDMS.  While  design  approaches  for  the  ARM  had  been 
developed  during  the  advanced  development  stages  of  the  SDMS  program,  its  final 
specifications  and  ultimate  hardware  development  were  initiated  as  a  result  of  the 
submarine  effort.  In  advanced  development  the  ARM  was  considered  as  a  cost-effec¬ 
tive  alternative  to  a  combination  AM  and  RM  in  small  ship  applications  or  in 
limited  applications  on  larger  ships.  The  study  identified  six  lOMs  unique  to  the 
FY80  SSN.  They  are  the  EM  Log,  BRD-7  Time,  Demand  Digital,  Depth,  Cavitation,  and 
Periscope  RPM.  Figure  6  illustrates  the  fully  integrated  EM  Log  interface. 

All  ship  systems  which  are  attached  to  the  SDMS  data  bus  have  full  access  to 
the  information  on  the  data  bus.  For  the  operator,  this  capability  was  provided 
through  a  Ship  Data  Display  Unit  (SDDU)  plasma  display,  with  touch-panel  selection 
of  the  information  displayed.  The  SDDU  information  is  displayed  in  characters  and 
graphics  which  can  provide  more  information  than  present  displays,  and  yet  the  SDDU 
requires  significantly  le^s  space  than  the  displays  it  replaces.  Programming  the 
SDDU  microprocessor  to  perform  arithmetic  computations  can  be  accomplished  so  that 
graphic  presentation  and  recommended  actions  can  be  given  to  the  operator  to  aid  in 
his  decision  making. 
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In  conjunction  with  the  SDMS  installation,  the  previously  required  central 
interior  communications  switchboard  power  distribution  and  action  cutout  (ACO) 
switching  provisions  were  deleted.  The  ACO  functions  were  incorporated  into  the 
lOUs.  Requirements  for  switching  also  could  be  met  by  modifying  user  equipments  or 
by  providing  a  small  switching  panel  designed  to  meet  established  needs.  A  combi¬ 
nation  of  both  approaches  will  most  likely  be  used.  This  will  provide  maximum 
flexibility  in  a  minimum  amount  of  space. 

In  that  SDMS  is  designed  for  easy  expansion  up  to  a  third  primary  bus  and  32 
ARMs,  growth  capacity  is  more  than  adequate.  The  total  FY80  SSN  data  load  was 
estimated  to  be  approximately  100K  bits  per  second  and  is  relatively  small  con¬ 
sidering  the  recommended  configuration's  gross  capacity  of  9.6M  bits  per  second. 
Reconfiguration  or  relocation  of  the  present  systems  serviced  by  SDMS  will  not 
require  major  redesign  of  ship’s  cabling,  Interfaces,  and  wireways.  The  inter¬ 
connections  will  be  accomplished  with  short  cable  lengths  from  users  to  Input/ 
Output  Units  (IOUs),  which  provide  access  to  and  from  the  data  bus.  To  install  a 
new  user  system  would  require  only  short  lengths  of  cable  linking  it  to  the  I0U  in 
the  vicinity  of  the  new  equipment.  Once  connected  to  the  IOU,  the  new  system  has 
full  access  to  the  ship's  data  bus.  This  feature  significantly  simplifies  instal¬ 
lation  of  new  equipment  and  improvement  of  installed  equipment  without  major 
changes  to  cable  runs  and  wireways. 

The  SDMS  Maintenance  Processing  Unit  (MPU)  continuously  monitors  the  entire 
SDMS.  When  a  fault  occurs,  both  an  audible  and  a  visual  alarm  are  generated  and 
the  MPU  indicates  which  part  has  failed,  down  to  the  lowest  replacement  unit  (LRU). 
The  MPU  may  be  read  and  the  LRU  replaced  by  third  class  1C  personnel.  Microminia¬ 
ture  circuit  repair  facilities  available  at  the  Navy’s  Intermediate  Maintenance 
Activities  should  be  able  to  repair  the  LRUs  and  return  them  to  the  supply  system. 


Although  the  elimination  of  those  interfaces  (e.g.t  BRD-7,  WLR-2)  which 
required  the  use  of  400Hz  power  was  encouraged,  none  were  eliminated,  the  reason 
being  that  the  redesign  of  those  equipments  to  incorporate  a  digital  interface 
could  not  be  assured.  As  a  result,  the  existing  400Hz  synchro  interfaces  were 
documented  in  the  study  report. 

DDG  47  STUDY 

Approach 

In  the  first  quarter  of  1978  the  study  to  develop  an  SDMS-based  interface 
design  for  the  DDG  47  Class  ships  was  initiated.  At  the  onset  it  was  recognized 
that  the  DDG  47  conventional  design  was  nearly  complete  and  that  an  SDMS  applica¬ 
tion  would  necessarily  incur  redesign  costs  which  would  otherwise  by  avoided  in  a 
new  design.  Nevertheless,  since  the  SDMS  development  schedule  is  compatible  with 
many  of  the  class  follow-on  platforms  and  since  some  design  changes  are  antici¬ 
pated,  it  appeared  that  the  DDG  47  Class  might  be  a  suitable  place  to  introduce 
SDMS  into  the  fleet,  even  if  in  a  restricted  application.  Therefore,  the  design 
approach  was  to  initate  the  analysis  at  a  broad-scale  applications  feasibility 
level  and  then  to  develop  a  design  which  concentrated  on  the  high  payoff  areas. 

The  study  was  organized  into  phases.  Phase  I  was  a  data  gathering  process 
which  required  the  tabulation  of  the  DDG  47  systems  interface  data.  Phase  II 
brought  in  cost  analysis  and  defined  various  configuration  options  and  associated 
costs.  Phase  II  produced  the  conceptual  design  for  the  SDMS  configuration  that 
will  be  most  beneficial  to  the  DDG  47  Class,  as  constrained  by  the  ground  rule  of 
minimal  redesign  impact  on  the  AEGIS  Combat  System. 

Results 

Phase  I  analysis  resulted  in  the  tabulation  of  over  6,000  point-to-point  data 
paths  that  can  be  multiplexed  in  an  SDMS  configuration.  More  than  two  thirds  of 
those  are  for  simple  two-state  discrete  signals  and  less  than  a  third  are  for  syn¬ 
chro  and  analog  scalar  type  signals.  Data  was  accumulated  for  another  300  NTDS 
digital  interfaces  primarily  for  NATO  interface  analysis.  Since  most  of  these 
signals  do  not  cross  compartment  boudaries  and  since  multiplexing  these  signals  is 
likely  to  incur  some  software  modifications,  the  multiplexing  feasibility  of  these 
signals  was  addressed  only  in  a  generic  sense.  No  final  conclusions  with  respect 
to  multiplexing  were  drawn  other  than  the  observation  that  most  of  the  signals 
require  a  data  throughput  capability  which  is  less  than  that  provided  by  each  of 
the  20  SDMS  data  channels.  About  5,000  of  the  6,000  point-to-point  data  paths  r 
signals  traverse  compartment  boundaries  and  therefore  constitute  the  primary 
multiplexing  candidate  set.  About  185K  feet  of  cabling  is  required  for  those  5,000 
signals  in  a  conventional  wiring  design. (3) 

In  addition  to  the  analysis  of  signals,  studies  were  conducted  to  assess  the 
functions  performed  by  various  switchboards  and  data  conversion  devices  to  deter¬ 
mine  whether  SDMS  could  provide  those  same  functions,  thereby  enabling  the  elimina¬ 
tion  of  those  devices  in  an  SDMS-based  design.  It  was  determined  that  more  than  a 
dozen  of  such  devices  could  be  replaced,  but  significant  systems  redesign  efforts 
would  be  required  in  many  cases.  An  important  observation  made  from  these  analyses 
is  that  in  a  top-down  design,  which  includes  the  integration  of  SDMS  from  the 
outset,  switching  and  conversion  functions  can  be  performed  by  SDMS  at  costs  equal 
to  or  less  than  those  for  conventional  counterparts. 

The  final  leg  of  Phase  I  analysis  developed  a  nonoptimized  and  transparently 
applied  SDMS  configuration  (e.g.,  to  reflect  only  the  multiplexing  of  the 
point-to-point  data  paths)  to  obtain  a  preliminary  assessment  of  the  numbers  ot 
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SCMS  elements  required  and  to  assess  SDMS  performance.  The  SDMS  configurati on 
consisted  of  the  following  elements: 

5  Traffic  Controllers  and  Primary  Buses 
8  Area  Multiplexers 
27  Remote  Multiplexers 
99  Input/Output  Modules 

1,210  Input/Output  Modules 
1  Maintenance  Unit 

Using  a  computer  program  which  simulates  SDMS  performance  for  a  given 
configuration  and  data  load,  it  was  determined  that  the  average  message  transport 
delay  was  182  microseconds.  The  data  load,  which  consisted  of  the  5,000  inter- 
compartment  signals  plus  a  few  NTbS  digital  interfaces,  had  a  1 . 9M  bit -per -second 
throughput  rate. 

Finally,  although  the  Phase  I  analysis  was  geared  toward  developing  a  data 
base  and  performing  a  preliminary  sizi ng/ performance  analysis,  it  became  apparent 
that  even  the  nonoptimized  SDMS  configuration  applied  on  a  transparent  basis  can 
result  in  cable  length  and  weight  savings.  Approximately  185K  feet  of  conventional 
cabling  would  be  impacted  with  a  net  weight  reduction  of  about  9  tons.  The 
replaceable  switchboards  and  conversion  devices  represent  another  5-ton  weight 
reduction  potential. 

Armed  with  the  data  base  and  SDMS  performance  analysis  results  from  Phase  I, 
the  project  directed  the  Phase  II  efforts  toward  the  refinement  of  various  SDMS 
applications  configurations  options  to  study  the  potential  impact  of  installation 
in  the  DDG  47  Class.  In  Phase  II,  the  applications  options  tradeoffs  v«re  examined 
and  economics  impact  was  considered. 

The  first  and  probably  most  important  lesson  learned  is  that,  excluding  the 
consideration  of  design  development  costs,  SDMS  will  break  even  at  best  on  costs 
with  respect  to  cabling  replaced  in  the  DDG  47  Class.  Therefore,  the  use  of  SDMS 
in  the  DDG  47  Class  should  be  predicated  on  factors  other  than  potential  dollars 
saved  due  to  reduced  cabling.  This  conclusion  is  likely  to  hold  for  most  top-down 
design  approaches  (where  no  redesign  costs  are  incurred)  as  well  as  in  almost  all 
retrofit  design  approaches. 

The  second  and  perhaps  as  important  conclusion  is  that  while  it  was  known  that 
ship’s  systems  invariably  include  switchboards  and  data  converters  that  in  most 
cases  can  be  replaced  by  SDMS,  it  was  not  generally  known  that  multiplexing  net¬ 
works  (that  are  potentially  replaceable  by  SDMS)  are  already  in  Navy  ships.  In 
fact ,  it  was  determined  that  the  DDG  47  design  includes  two  such  multiplexing  net¬ 
works  (e.g.,  ORTS  and  PAM1SE)  although  neither  is  a  broad  based  network  such  as 
SDMS.  Furthermore,  it  was  determined  that  new  subsystems  designs  are  likely,  in 
many  cases,  to  require  some  type  of  data  distribution/multiplexing  network.  There¬ 
fore,  the  question,  as  had  been  presupposed  at  the  outset  of  the  project,  is  not 
whether  multiplexing  should  be  introduced  Into  the  fleet,  but  rather  how  should  it 
be  implemented.  More  specif ically,  the  tradeoff  is  one  of  the  use  of  a  widely 
applied  and  standardized  network  such  as  SDMS  vice  the  use  of  smaller  limited 
application,  but  tailored,  specialized  multiplexing  networks. 

Going  back  to  SDMS  application  to  the  DDG  47,  while  it  is  clear  that  SDMS  does 
not  result  in  a  net  cost  saving  when  applied  only  to  replace  cable,  the  cost  pic¬ 
ture  becomes  substantially  better  if  switchboards  and  conversion  devices  are 
replaced.  In  fact,  a  top-down  design  which  uses  SDMS  In  place  of  such  devices  is 
likely  to  be  significantly,  but  not  overwhelmingly,  cheaper  than  the  conventional 
counterpart.  But  In  the  case  of  the  DDG  47  Class,  the  potential  savings  are  not 
enough  to  overcome  the  initial  DDG  U1  systems  redesign  costs.  Furthermore,  exten- 
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sive  design  changes  to  the  AEGIS  Combat  System  are  considered  undesirable  at  this 
time  due  to  the  technical  and  schedule  risks  involved. 

Therefore,  the  issue  facing  the  study  project  was  whether  to  recommend  the 
maximum  application  of  SDMS  to  the  DDG  47  Class  and  attempt  to  justify  the 
increased  expenditures  on  the  basis  of  weight  savings,  enhanced  survivability,  and 
increased  flexibility,  or  to  search  for  some  lesser  application  which  minimized 
expenditures  and  zeroed  in  on  the  high  payoff  areas.  The  project  decided  to  recom¬ 
mend  that  SDMS  be  installed  in  the  DDG  47  Class  on  a  limited  application  basis  for 
the  following  reasons. 

First,  to  establish  what  constituted  a  high  payoff  area  it  was  necessary  to 
address  the  advantages  provided  by  SDMS  and  then  determine  how  these  advantages 
impacted  various  applications  areas.  In  the  Navigation  area,  it  was  observed  that 
the  weight  reduction  payoff  was  substantial  because  the  heavier  types  of  cabling 
and  the  major  portions  of  the  Main  Interior  Communications  Switchboards  were  elimi¬ 
nated.  Also  in  this  area,  the  enhanced  survivability  provided  by  SDMS  is  important 
because  these  Navigation  signals  are  critical  to  many  user  systems.  Additionally, 
via  the  use  of  SDMS  the  switching  of  the  Navigation  Gyros  can  be  automated  and 
reaction  time  to  a  failed  Gyro  can  be  reduced.  Therefore,  the  Navigation  signals 
(about  200  signals)  constitute  a  high  payoff  area  with  the  important  parameters 
being  weight  reduction,  increased  survivability  and  switching  flexibility.  How¬ 
ever,  since  only  about  6,000  feet  of  conventional  cabling  is  replaced  by  multi¬ 
plexing  in  this  area,  cabling  cost  savings  do  not  offset  the  costs  of  the  multi¬ 
plexing  hardware  required.  Nevertheless,  the  functional  gains  arc  readily  identi¬ 
fiable  and  it  is  clear  that  a  specific  systems  enhancement  results  from  the  expen¬ 
diture  . 

A  second  area  of  fruitful  application  is  the  Damage  Control  network. (^) 
Unlike  the  more  critical  Gyro  signals  in  the  Navigation  area,  each  Damage  Control 
signal  is  of  lesser  relative  importance,  and  therefore,  enhanced  survivability  is 
not  as  important.  However,  the  use  of  the  SDMS  in  this  area  impacts  about  500 
signals  and  60K  feet  of  cabling.  Since  most  of  these  signal  types  are  discretes, 
which  are  the  cheapest  signals  to  multiplex  with  respect  to  I/O  conversion  costs, 
and  since  one  third  of  the  185K  feet  of  cabling  is  impacted,  the  Damage  Control 
network  provides  a  good  weight  reduction  return  for  dollars  spent.  More  impor¬ 
tantly,  the  Damage  Control  data  now  becomes  available  at  many  points  other  than 
Damage  Control  Central  and  can  enable  the  implementation  of  a  backup  Damage  Control 
station/display  without  the  need  for  substantial  amounts  of  new  cabling.  Addition¬ 
ally,  if  a  computerized  Damage  Control  Central  evolves  (the  present  one  is  strictly 
a  non-intelligent  analog  display),  SDMS  can  readily  deliver  the  data  to  such  a 
complex  in  a  digital  format.  Conversely,  if  SDMS  is  not  implemented  in  this  net¬ 
work  and  a  computerized  complex  is  to  be  implemented,  a  new  data  converter  require¬ 
ment  will  arise.  Damage  Control  is  a  good  example  of  the  type  of  network  which 
will,  when  computerized,  require  either  new  data  converters  and/or  a  new  data  dis¬ 
tribution  network.  It  illustrates  a  specific  example  of  how  SDMS  can  provide  an 
important  payoff  other  than,  but  in  addition  to,  the  replacement  of  cabling. 

Another  applications  area  which  results  in  an  immediate  payoff  is  the  pooling 
of  teletype  consoles.  In  this  application,  which  involves  only  a  small  amount  of 
cabling,  the  SDMS  switching  capabilities  are  used  to  enable  the  C£D  computers  to 
access  and  share  the  low  data  rate  teletypes.  By  so  doing,  four  teletype  consoles 
can  be  eliminated  and  a  2-ton  weight  reduction  results.  Furthermore,  the  computers 
would  now  have  access  to  any  other  data  in  SDMS  and  can  communicate  with  any 
devices  (e.g.,  present  or  future)  connected  to  SDMS. 

In  each  of  the  above  applications  areas  the  use  of  SDMS  in  place  of  the  con¬ 
ventional  network  results  in  a  specific  advantage  or  set  of  advantages*  Cost  anal¬ 
ysis  has  shown  that  the  implementation  of  any  SDMS  configuration  in  the  DDG  47  will 
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not  pay  for  itself.  This  is  due  largely  to  the  redesign  costs  associated  with  this 
bottom-up  design  approach.  By  limiting  the  configuration,  SDMS  becomes  introduced 
into  the  DDG  4?  Class  at  minimal  costs  and  provides  immediate  returns  as  described 
above.  Furthermore,  SDMS  would  then  be  resident  to  accommodate  the  data  distribu¬ 
tion/conversion/switching  capabilities  that  will  be  necessary  to  support  new  sys¬ 
tems  as  they  are  integrated  into  the  design.  The  consequence  of  not  implementing 
SDMS  is  that  more  specialized  converter  boxes,  switchboards,  and  specially  tailored 
data  distribution/multiplexing  networks  will  evolve,  and  from  the  preliminary  cost 
analysis  conducted  on  such  devices  and  networks  already  In  the  DDG  47,  it  appears 
that  these  new  elements  will  be  more  expensive  than  SDMS  in  the  long  run,  primarily 
because  unnecessary  new  design  costs  will  be  perpetuated. 

As  an  aftermath,  It  is  clear  that  the  best  way  to  integrate  a  wide  scale 
application  multiplexing  network  is  to  include  it  in  the  initial  systems  design. 
In  the  case  of  the  DDG  47  retrofit  design,  maximum  appliction  is  not 
cost-effective,  but  the  limited  scale  application  selected  results  in  near-term 
gains  and  anticipated  long-term  advantages  which  are  judged  to  be  worth  the 
expenditures. 

CONCLUSIONS 

The  DDG  47  and  SSN  submarine  studies  both  developed  SDMS  configuration  designs 
which  do  not  make  maximum  use  of  SDMS,  but  rather  restrict  SDMS  appliction  to  those 
areas  which  result  in  an  immediate  payoff.  While  the  two  applications  are  similar 
in  that  regard  it  is  interesting  to  note  that  they  each  resulted  from  two  different 
design  approaches.  A  boc tom-up  design  approach  drove  the  DDG  47  application  while 
a  top-down  approach  was  used  for  the  SSN  submarine  application. 

At  the  outset  of  both  of  the  studies  it  was  preconceived  that  saving  cable  was 
the  primary  applications  factor,  but  it  was  subsequently  learned,  and  is  in  fact 
reflected  in  the  configuration  designs,  that  benefits  other  than  cable  savings  are 
probably  more  important  from  an  overall  ship  design  point  of  view.  For  example,  in 
the  DDG  47  design,  enhanced  survivability  and  automated  switching  is  particularly 
important  in  the  Navigation  area.  In  the  teletype  console  pooling  application, 
equipment  reduction  and  space/weight  savings  are  important.  In  the  Damage  Control 
application,  the  availability  of  Damage  Control  data  at  alternate  locations  is 
important  plus  the  fact  that  the  data  can  be  delivered  in  digital  Form  to  input  to 
a  computer.  In  the  submarine  study,  SDMS  was  used  primarily  to  save  space  via  sys¬ 
tem  integration  and  equipment  reductions  and  to  facilitate  interface  design  where 
changes  were  already  planned.  In  addition,  SDMS  in  conjunction  with  the  Ship  Data 
Display  Unit  (SDDU)  greatly  enhanced  the  availability  of  Navigation  data  throughout 
the  submarine.  The  major  point  here  is  that  while  SDMS  saved  cable  in  both  appli¬ 
cations,  the  major  advantages  of  using  SDMS  related  to  factors  other  than  cable 
savings.  Furthermore,  while  multiplexing  is  what  enables  cable  savings,  it  is  the 
I/O  adaptivity  (provided  by  the  ICMs)  which  makes  possible  most  of  these  "other” 
gains.  Cost  analysis  in  the  DDG  47  study  revealed  that  more  than  half  the  cost  of 
SDMS  is  attributable  to  input/output  signal  conditioning.  This  is  probably  why 
SDMS  is  not  cost-effective  when  used  only  to  replace  cabling  in  the  DDG  47  Class. 
In  a  "pure  multiplexing”  network  the  subscribers  would  all  be  required  to  "speak" 
the  multiplexing  language  or,  in  other  words,  bear  the  burden  of  providing  data  in 
a  standard  format.  Under  such  circumstances,  it  is  likely  that  a  "pure 
multiplexing"  network  would  prove  cost-effective  as  applied  only  to  saving  cable. 
But  since  this  is  not  the  case,  it  is  apparent  that  SDMS  application  beyod  the  mere 
replacement  of  cabling  is  what  is  required  If  the  cost  of  SDMS  Is  going  to  be  prop¬ 
erly  amortized.  That  is,  in  essence,  the  message  Implied  by  the  designs  developed 
for  the  DDG  47  and  submarines. 
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